doc/internal/release/versioning.md
Our versioning strategy is based on VEP5.
A new major release is needed when the public API changes in a backward-incompatible way -- for example, when removing deprecated interfaces.
Our public API includes (but is not limited to):
Care must also be taken when changing the format of any data stored by a live system, such as topology data or Vitess-internal tables (used for sequences, distributed transactions, etc.). Although this data is considered as internal to Vitess, if any change breaks the upgrade path for a live system (for example, requiring that it be shut down and reinitialized from scratch), then it must be considered as a breaking change.
A new minor release indicates that functionality has been added or changed in a backward-compatible way. This should be the majority of normal releases.
A patch release indicates that only a select set of bugfixes have been
cherry-picked onto the associated minor release. The expectation is that
upgrading by a patch release should be painless (not requiring any config
changes) and safe (isolated from active development on main).
Pre-release versions should be labeled with a suffix like -beta2 or -rc1.