Skip to content
Bryan Call edited this page Mar 19, 2026 · 2 revisions

Release Process

This page covers how Apache Traffic Server releases are managed, including versioning, branches, and the release procedure.

Version Numbering

ATS uses semantic versioning: major.minor.patch

  • Major (e.g., 9 → 10): Significant changes, may break backward compatibility
  • Minor (e.g., 10.0 → 10.1): New features, backward compatible
  • Patch (e.g., 10.1.0 → 10.1.1): Bug fixes and security patches

Current active versions (as of early 2026):

  • 10.1.x — Latest stable
  • 9.2.x — Previous LTS

Release Branches

  • master — Active development, next major/minor release
  • 9.2.x, 10.0.x, 10.1.x — Release branches for maintenance

All new development goes into master. Bug fixes and security patches are backported to active release branches.

Release Manager Responsibilities

Each release branch has a designated Release Manager (RM) who:

  • Manages the release branch
  • Reviews and merges backport PRs to the release branch
  • Drives the release process (tagging, packaging, voting)
  • Coordinates security fixes

Only the RM should merge PRs to their release branch.

Backport Policy

Changes are backported from master to release branches when:

  • They fix bugs present in the release branch
  • They fix security vulnerabilities
  • They are safe, low-risk improvements

Backport PRs:

  • Must have the Backport label
  • Must target the release branch (not master)
  • Are reviewed and merged by the Release Manager
  • Should reference the original master PR

Creating a Release

The release process follows Apache release guidelines:

  1. Ensure all intended commits are in the release branch
  2. Update version numbers in configure.ac and trafficserver.spec
  3. Generate changelog from GitHub Milestone tags (make changelog)
  4. Commit the changelog and version updates
  5. Generate release candidate tarball (make rel-candidate)
  6. Push the RC tag to the repository
  7. Upload tar files for review
  8. Have someone verify the build, SHA checksums, signatures, etc.
  9. Call for a vote on the dev mailing list

Voting

Release votes follow the Apache voting process:

  • Votes run for at least 72 hours
  • Requires at least 3 binding +1 votes (PMC members)
  • More positive than negative binding votes
  • Release manager does not have an implicit +1

After the vote passes:

  1. Remove the RC suffix from the tarball
  2. Publish to Apache release distribution
  3. Update the TrafficServer website with the new version

Publishing

svn checkout https://dist.apache.org/repos/dist/release/trafficserver/
cd trafficserver
mv ../trafficserver-${version}.tar* .
svn add trafficserver-${version}.tar*
svn commit . -m "Release ${version}"

See Also

Clone this wiki locally