Long-Term Support Branch Maintenance Workflow

Maintain a stable branch with backported fixes only, a defined support window, and an explicit upgrade path for consumers on it.

intermediate~30 minreleasemaintenancesupport

Objective

Keep a supported older release healthy with security and critical fixes while making its eventual end-of-life a planned, communicated event.

Environment

A release line designated LTS with consumers on it
Backport capacity reserved in the team
A published support policy

Steps

1. Publish the support policy

Define what the LTS branch receives (security fixes, critical bugs) and its end-of-support date, communicated to every consumer.

Expected state: The policy is documented, dated, and acknowledged by major consumers.

2. Triage fixes for backport

At each regular release, classify fixes as must-backport (security, critical) or main-only, with the backport set tracked per LTS release.

Expected state: Every qualifying fix lands on the LTS branch within the policy window.

3. Backport with tests intact

Cherry-pick fixes including their tests, adapt only where APIs diverged, and run the LTS branch suite on every backport PR.

Expected state: Backported commits carry their tests, and the LTS pipeline stays green.

4. Bump patch versions and notify

Release LTS patch versions on the backport cadence, with notes distinguishing them from mainline releases.

Expected state: Consumers can distinguish LTS patches from mainline releases at a glance.

5. Drive the end-of-life plan

As end-of-support approaches, escalate upgrade nudges (90, 30, 7 days), verify the upgrade path works, then archive the branch.

Expected state: The branch reaches EOL with consumers migrated or having explicitly accepted the risk.

Expected outcome

An LTS line that stays safe to run, receives qualifying fixes within the policy, and ends its life as a managed transition rather than an abandoned branch.

Verification

LTS patch history shows all qualifying security fixes within the policy window; the EOL date arrived with migration evidence for major consumers.

Cleanup

Archive the branch with a final notice and a pointer to the upgrade guide.

An LTS branch is a promise with a calendar

Supporting an old release is a commitment: which fixes, for how long, with what upgrade story. Publishing the policy first makes the branch a managed product; leaving it implicit makes it a graveyard that security fixes never reach.

LTS 1.x  (support policy v2)
  receives:    security (<=7d), critical (<=14d)
  NOT:        features, refactors, mainline deprecations
  end-of-support: 2027-04-30

backport ledger (excerpt):
  CVE-2026-4411  auth bypass       backported 2d   v1.8.9
  #4921 rounding  critical         backported 5d   v1.8.9
  #5102 caching   main-only        (not qualifying)

EOL nudges: 2027-01-30 / 2027-03-30 / 2027-04-23

The backport ledger is the trust artifact

Consumers stay on an LTS line because someone verifies it receives the fixes that matter. A public ledger mapping every security advisory and critical fix to its backport (or its main-only classification) is what makes the promise checkable rather than aspirational.

EOL is a campaign, not a date

Announcing end-of-support on the day it happens strands consumers and generates anger. Escalating nudges at 90, 30, and 7 days, with a verified upgrade guide, converts the end of a branch into a managed migration.