Release Process

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

Where the version is defined depends on the branch's build system:

Branch	Build system	Version defined in
9.2.x	autotools	configure.ac — m4_define([TS_VERSION_S],[9.2.15]) and m4_define([TS_VERSION_N],[9002015])
10.x and later	CMake	CMakeLists.txt — project(ats VERSION 11.0.0)

On 9.2.x both macros must be updated together: TS_VERSION_S is the display string and TS_VERSION_N is the numeric form (major × 1000000 + minor × 1000 + micro).

For the versions that are currently supported and released, see the Downloads page and the Release Roadmap. Those are the authoritative sources — this wiki deliberately does not duplicate a version list, because it goes stale between releases.

Release Branches

• master — Active development, next major release
• <major>.<minor>.x (for example 10.2.x, 10.1.x, 9.2.x) — Maintenance branches

Each maintenance branch is cut from master and maintained by a Release Manager. See the branch list on GitHub for what currently exists.

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 authoritative, step-by-step procedure is Release Procedures in the official documentation. It is maintained alongside the build system, so follow it rather than this summary if the two ever disagree.

The outline is the same on every branch:

1. Ensure all intended commits are in the release branch
2. Update the version number (see Version Numbering for where it lives)
3. Generate the changelog from the GitHub Milestone
4. Commit the changelog and version updates
5. Build and sign the release candidate tarball, which also creates the RC tag
6. Push the RC tag to the repository
7. Upload the tarballs for review
8. Have someone independently verify the build, SHA512 checksums, and GPG signatures
9. Call for a vote on the dev mailing list

The commands differ by branch, because the build systems differ. ATS 9.2.x is built with autotools; ATS 10 and later are built with CMake. The target names are the same in both, so be sure you are using the right invocation for the branch you are releasing.

9.2.x (autotools)

# Generate the changelog (needs a GitHub token)
make changelog AUTHTOKEN=<github-token>

# Release candidate: tarball + signature + <version>-rc<N> tag
RC=1 make rel-candidate

# Final release: tarball + signature + <version> tag
make release

The changelog target runs tools/git/changelog.pl against the GitHub Milestone and writes CHANGELOG-<version>.

10.x and later (CMake)

# Release candidate: tarball + signature + <version>-rc<N> tag
RC=1 cmake --build build -t rel-candidate

# Final release: tarball + signature + <version> tag
cmake --build build -t release

The CMake build has no changelog target, but the script it wrapped is still in the tree. Run it directly:

./tools/git/changelog.pl -o apache -r trafficserver -m <version> -a <github-token> \
  > CHANGELOG-<version>

This is the same tools/git/changelog.pl that make changelog invokes on 9.2.x — only the wrapper target is missing, not the tooling. The -m argument is the GitHub Milestone name, which must match the release version exactly, and -a is a GitHub token (without one you will hit the API rate limit).

Release Targets

Both build systems define the same chain of targets:

Target	What it does
asf-distdir	Assemble the distribution directory
asf-dist	Create the release distribution tarball
asf-dist-rc	Create the release candidate tarball
asf-dist-sign	Create the release tarball with SHA512 and a detached GPG signature
asf-dist-sign-rc	Same, for a release candidate
release	asf-dist-sign plus a signed <version> git tag
rel-candidate	asf-dist-sign-rc plus a signed <version>-rc$RC git tag

rel-candidate reads the RC number from the RC environment variable, so RC=1 produces <version>-rc1.

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

• Contributing — How backport PRs work
• Code Review — Merge policy for release branches
• Apache Release Management — ASF release guidelines
• ATS Release Procedures — Detailed steps in the official docs
• ATS Release Roadmap — Planned releases