THIS IS A DRAFT FOR DISCUSSION
MXNet Versioning is based on the definition from https://semver.org:
Given a version number MAJOR.MINOR.PATCH, increment the:
- MAJOR version when you make incompatible API changes,
- MINOR version when you add functionality in a backwards-compatible manner, and
- PATCH version when you make backwards-compatible bug fixes.
Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
We always use master branch as the main development area. When there is a date for releasing a new version (minor or major) one, we cut a new branch and announce code freeze for that version (of course, there is some exception to merge the previously-ignored blockers to the newly cut branch). Following Apache release rules we are creating release candidates for the community to vote. If needed, we will merge previously-ignored blockers to the release branch and iterate on voting until we have a valid release.
After a minor or major release we continue to use master branch for future development and cautiously backport critical patches to the branch from the latest major/minor release. For a PR to be considered critical for backporting we should have at least 3 votes on github. While there should be no limitations for the community on back merges into older branches, we will create only patch releases on the most recent major or minor release.
We will protect release branches and apply regular regressions as soon as our CI/CD setup can support branches. In the meantime, we will have to rely on manual testing.