This is our current release schedule and process. The primary goal here is to have one LTS release branch / year, each such branch is LTS for 2 years.
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
When we upload a tar ball to VOTE on as a new release and it does not work out, because something is broken and needs a code-change we will not reuse the version number. The rationale behind this is the process which guarantees that what we release and what's in the tree is also what everyone has seen so far and no code is sneaked in. If for instance we had a release candidate trafficserver-4.1.4-rc1.tar.bz2 (note the rc1 at the) end, and that vote passed, we'd re-roll the tar-ball to make sure it will simply be called trafficserver-4.1.4.tar.bz2. But now all sha1 and md5 sums as well as the GPG signature would also be different. That's the perfect opportunity to smuggle in some code that no one will bother to review any more.
Therefore when creating a new release the first thing we do is create a signed tag and push it. That way everyone can compare that signed tag with the signed tar-ball that we create from the tag and upload it (usually to people.apache.org).
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.
The following release managers have agreed to fill the current and upcoming releases.
First release date
|5.3.x||Phil Sorber (LTS)||May 2015||November 2016|
|6.0.x||Bryan Call||Leif Hedstrom||September 2015||January 2016|
|6.1.x||Leif Hedstrom||January 2016||May 2016|
|6.2.x||Phil Sorber (LTS)||June 2016||December 2017|
|7.0.0||Bryan Call||Leif Hedstrom||October 2016||January 2017|
|7.x||Leif Hedstrom||Bryan Call||May 2017||June 2019|
|8.x||Bryan Call||Leif Hedstrom||August 2018||September 2020|
|9.x||TBD||June 2019||July 2021|
Each release manager is responsible for the primary, minor release, as well as any patch releases within that minor release. Note that patch releases are primarily for truly critical bugs, and security issues. Don't expect minor fixes or feature additions in a patch release, those happens on each quarterly release.