Release branches — when stable releases matter and what maintenance costs

A release branch is a branch that holds a named, stable version of the system — release/v1.2, release/2024-q3, lts/2023. The branch is cut from the trunk at a moment in time, tagged with a version, and then maintained: bug fixes land on the branch, security patches backport from the trunk. The branch lives for as long as the version is supported — months or years.

Release branches are not the trunk-based default. They exist for cases where the team needs to ship a named version and continue supporting it after the trunk has moved on. The cost is real and ongoing.

When a release branch is worthwhile

A release branch is worthwhile when the team needs named, stable versions maintained over time. Three situations drive this:

• LTS releases. A team promising to support v1.2 for two years must keep a branch that holds v1.2 and accept fixes on it.
• Contractual support windows. A vendor that contracts to deliver security patches for a named version must keep a branch for it.
• Regulated environments. A regulated industry may require that production changes be tied to a named, audited version.

flowchart LR
    T1["v1.0"] --> T2["v1.1 dev"] --> T3["v1.2 dev"]
    L1["v1.0.0"] --> L2["v1.0.1"] --> L3["v1.0.2"]
    T1 -->|"cut"| L1
    L2 -->|"cherry-pick"| L2
    L2 -->|"merge back"| T2

The diagram shows the release-branch shape: the trunk moves forward, the release branch stays at the named version, fixes flow trunk→release (cherry-pick) and release→trunk (merge).

The cost of maintenance

Three costs accumulate. Cherry-pick overhead: every security fix on the trunk must be evaluated for the release branch. A six-month-old release branch may require manual re-implementation for half the fixes; a one-month-old branch cherry-picks cleanly. Drift from the trunk: the release branch is a fork; the longer it lives, the larger the drift. Security backport complexity: security patches are time-sensitive — the patch must be tested against the release branch’s configuration and runtime; the testing infrastructure is duplicated.

The merge-back discipline

The discipline has two parts. (1) Every fix on the release branch merges back to the trunk — either as a forward-merge of the release branch, or as a cherry-pick of the release-branch commit into the trunk. (2) Every fix on the trunk is evaluated for the release branch — cherry-picked if relevant, left on the trunk if not. The evaluation is explicit, not implicit.

BRANCH="release/v1.2"

git switch "$BRANCH"
git cherry-pick $COMMIT_SHA
git push origin "$BRANCH"

git switch main
git merge --no-ff "$BRANCH"

When not to use a release branch

Three signals indicate a release branch is not warranted: (1) no versioned deployment (the team deploys the trunk tip); (2) short support windows (one week does not need a branch); (3) fast-moving trunk (multiple deploys per day leaves no time to maintain a fork). For these teams, trunk-based is correct; the release branch is added when the team takes on the responsibility of supporting a named version.

Production discipline

1. Cut the release branch at a known point. Cut from a tagged commit on the trunk.
2. Name the branch clearly. release/v1.2, lts/2023. The name encodes the version and window.
3. Merge back on every fix. CI enforces; CONTRIBUTING.md documents.
4. Audit the gap monthly. A release branch more than N commits behind has drifted.
5. Retire the branch on the support-window end date.

Cross-course references

• GitOps with Argo CD - Part VII (MultiEnv) covers multi-version management with sync windows.
• CI/CD Pipeline Patterns - Part VI (ReleasePipelines) covers the release pipeline that tags a branch.
• Terraform for Production Sysadmins - Part XIII (ModuleVersioning) covers module versions with the same merge-back discipline.

Quiz