Define release cadence/versioning schema
Standardizing on a versioning scheme
- What does Major, Minor, Patch mean?
- What changes can customers expect in each?
- Can a breaking change come in a major release? Minor release? Patch?
- Will changes in minor/patch be backwards compatible?
- Major version changes indicate to a user that there are more things to look out for in the release notes.
- There is a need to clarify what these things means today.
Standardizing on a release cadence
- Do we continue 2 week standard release cycle? More or less frequent releases?
- Big Bang should provide additional transparency on what is driving the release cadence & the requirements; ex: Who decides what features get added, cut, or improved upon in each release? How can this process be made more accessible?
Objective
The output of this issue should be an ADR for review by the team. Suggest following the format of this post to capture context, decision, status, and consequences. Once this ADR is accepted by the team, the proposed versioning structure/release cadence should be documented as part of BB docs.
Keep in mind the primary objectives here:
- Provide clear documentation of what goes into each BB release (if a customer sees a new minor release, what does that mean?)
- Reduce customer pain re:"hard to keep up" (this doesn't mean we have to release less often)
Edited by Micah Nagel