Skip to content

Backporting policy

Which release lines receive ongoing fixes, for how long, and the mechanics for cherry-picking a fix back to an older line.

Supported lines

At any moment, three release lines are supported:

Line Receives Until
Current minor (e.g. v3.7.x) Bug fixes · feature work · security fixes · doc updates Superseded by the next minor
Previous minor of current major (e.g. v3.6.x when v3.7.x ships) Security fixes · critical bug fixes · regression fixes 3 months after the next minor ships (overlap window)
Latest minor of previous major (e.g. v2.x when v3.x is current) Security fixes only 12 months after the next major ships, then end-of-life

Anything not in the table is end-of-life — no fixes, no support. The cut-off is announced in CHANGELOG.md and listed in SECURITY.md § Supported versions.

What gets backported

Change kind Current minor Previous minor (overlap window) Previous major (security only)
New feature ✅ ❌ ❌
Refactor ✅ ❌ ❌
Regression fix (introduced by a recent feature) ✅ ✅ ❌
Critical bug fix (production-blocking) ✅ ✅ ❌
Non-critical bug fix ✅ maintainer discretion ❌
Security fix ✅ ✅ ✅
Doc fix ✅ rare ❌
Dependency bump ✅ only if security-driven only if security-driven

The bar is intentionally high on backports — every backport multiplies the maintenance surface for a solo project. We do security with no hesitation; everything else gets weighed.

Mechanics — how a backport happens

A backport is a separate PR against a release/vX.Y branch (not against main). Process:

  1. Fix lands on main first via normal PR review. Tag the PR with release-blocker if it must ship before the next routine release.

  2. Open backport PR(s) — one per target line:

  3. Branch name: backport/<source-pr-number>/<target-line> (e.g. backport/672/v3.6)
  4. Target branch: release/v3.6 (or whichever line)
  5. PR title prefix: backport: (preserves Conventional Commits compliance — the original commit prefix is preserved in the body)
  6. Body cites the original PR + the security advisory ID if applicable

  7. Quality gates: same as a routine PR (CI green, tests pass, CODEOWNERS sign-off for Tier B paths)

  8. Cherry-pick via git cherry-pick -x <commit> (the -x adds a "cherry picked from ..." footer that survives squash — audit trail).

  9. Conflicts — common when the surface area has drifted. The backporter resolves and notes the resolution in the PR body. Never silently squash conflict resolution into the same commit as the cherry-pick — keep them as separate commits so an auditor can see what changed.

  10. Tag a patch release on the target line: vX.Y.Z+1 (or vX.Y.Z-security.1 for security-only releases that need a distinct version).

  11. CHANGELOG.md update lands on both main (for record) and on the target line. The target-line CHANGELOG section is the one the customer reads.

Security-only backports — fast path

When the source is a closed security advisory, the backport flow compresses:

  • Source commit lands on main behind closed-source coordination with the advisory reporter
  • Coordinated disclosure date is fixed in the advisory
  • Backport PRs for every supported line open simultaneously, remain private (advisory feature) until disclosure date
  • Tagging happens on the disclosure date for all affected lines at once
  • CHANGELOG entry uses the advisory CVE/GHSA number as the primary reference

The SLA is in SECURITY.md § Response SLA: 5 business days from advisory acknowledgement to patch release.

When a release line goes end-of-life

EOL is announced at least 30 days before the cutoff in two places:

  1. CHANGELOG.md — Deprecated section of the most-recent release on the line being retired
  2. SECURITY.md Supported versions table — line moves from Security fixes only to ❌ No longer supported

The retired line's release/vX.Y branch is left in place (we don't delete history) but marked archived in a top-of-branch README. Customers running that line are encouraged to migrate via the migration docs.

Why this matters

Regulated-sector customers procuring TLSStress.Art will ask: "If a CVE drops on v3.6 after we deploy and v3.8 is current, do you fix v3.6?" This document is the answer — and the answer is yes, within the supported-line table above.

For audit / valuation, the existence of a written backporting policy + a SECURITY.md SLA combine to materially affect the "security maturity" score of an enterprise software due diligence.

Last verified against shipping code: v3.7.0 (2026-05-12).