Skip to content

docs: document SemVer adoption and usage

Oscar Tovar requested to merge otovar/add-versioning-documentation into main

Description

As discussed in this internal Slack thread, it would be good to document how we manage breaking changes in special scenarios. The scenarios that I included were:

  • Security bugs
  • Functional bugs (users should not depend on buggy behavior)
  • Confusing behavior
  • Experimental features (opens up the door for us to experiment in the CLI and gauge interest on certain features)

I used the Go compatibility promise expectations, and the security report schema project as inspiration for these changes.

Related Issues

Resolves #[issue_number]

N/A

How has this been tested?

N/A

Screenshots (if appropriate):

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation
  • Chore (Related to CI or Packaging to platforms)
  • Test gap

Merge request reports