Skip to end of metadata
Go to start of metadata

This is a proposal to change how we cut, vote and prepare new releases. In a nutshell, it comes down to eliminating the development releases, in favor of more and frequent stable releases.

Versions, compatibility and schedules

  1. We promise to make 4 releases / year, but the RM and community can of course make more as necessary. Master is the primary release branch, but RMs can use whatever methodologies to make the process easy.
  2. There is no longer an odd-even release. We'll make 4.0.0, 4.1.0, 5.0.0 and 5.1.0 based on Semantic Versioning.
  3. There is no voting / backporting on commits to a stable branch. CTR applies to all master changes still.
  4. A best-effort to keep compatibility should be made; don't break compatibility for no good reason.
  5. Commits that breaks compatibility are not allowed on master. Such changes gets committed instead on a next-incompatible-rev branch (call it 5.0.x).
    1. That said, API in experimental.h and plugins under experimental/ may be modified at any time.
  6. Annually (or as agreed upon, TBD?) we make a decision if it's time to make an incompatible release, and if so, the next-incompatible-rev (5.0.x) branch is merged to master.
  7. The last minor version before an incompatibility break becomes an LTS release branch that we maintain security and critical fixes on, for one additional year.

Current Release Schedule and support

Note: Only the "green" releases are planned, yellow Patch releases are only shown here as examples. The goal is to have as few patch releases as possible, i.e. only for critical bug fixes and security issues.

The old Roadmap for current release cycle only applies up until v5.2.0, the above takes affect as of v5.3.0 and forward. v4.2.x will be supported until August 2015.


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.

Backporting to current stable release

The point of the new system is that we'd prefer to not back port bugs to the stable branch (e.g. 4.0.x). The exceptions are truly critical fixes which can not wait for the next quarterly release. This includes security fixes, and frequent crashing bugs.

The committer of a fix is responsible to mark a bug that he's fixed / resolved on master with a backport target if appropriate; e.g. 4.0.2. The release manager will pick these up, and if appropriate, merge the commit(s) to the release branch. After doing so, the RM (release manager) will mark the Fix Version of the Jira ticket with both the next minor version (e.g. 4.1.0) and the back port version (e.g. 4.0.2), and can thereafter remove the back port target from the ticket.

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

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 upcoming releases.


Primary RM

Secondary RM

First release date

Supported until


Phil Sorber (LTS)


February 2014

May 2015


Bryan Call

Leif Hedstrom

June 2014

August 2014


Alan M. Carroll


August 2014

November 2014

5.2.xLeif Hedstrom November 2014February 2015
5.3.xPhil Sorber (LTS) February 2015May 2016
6.0.xIgor GalicLeif HedstromMay 2015August 2015
6.1.xBryan Call August 2015November 2015
6.2.xAlan M. Carroll February 2016May 2016
6.3.xPhil Sorber (LTS) May 2016May 2017

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.


  • No labels