...
For details on the actual release process (for release managers), see the Docs page.
Versions, compatibility and schedules
- We promise to make 1 release / year, but the RM and community can of course make more as necessary
- We only make releases off the LTS branches, which are cut once a year off master
- Master is always open, for any type of change (including incompatible changes). But don't break compatibility just for fun!
- Master is always stable, i.e. commits should be properly tested and reviewed before committed to master.
- All releases are stable releases, following strict Semantic Versioning.
Current Release Schedule and support
Note: These are examples, only the first minor release number of each major LTS branch is guaranteed to be made.
...
As you can see, we no longer make any sort of development releases. Also, there's no longer a backport voting process! The latter means that all developers and users must make a higher commitment to reviewing changes as they go into master and the incompatible release branch. Other than that, it's pretty much business as usual, but easier for everyone involved. This git branch diagram shows an example how the git tree will be managed:
Making minor releases within an LTS branch
Burning release numbers, or how our release process works
...
Now, when we notice an issue that needs a code-change, we make that on master, cherry-pick it to the release-branch (optional), and create the new tag.
Release managers
The following release managers have agreed to fill the current and upcoming releases.
...