Long-Term Support: Branches, Backports, and End of Life In short: Some teams cannot upgrade on your schedule. Support the current major plus two, automate the backports, and publish an end-of-life date — because an unwritten support policy always means "forever". In a monorepo everything upgrades together. Across an organisation with independent repositories and release trains, it does not. The farmer portal adopts v12 the week it ships. The dispatch dashboard is inside a compliance audit and frozen on v10 until the quarter closes. Then a serious accessibility bug is found in a shared component. "Upgrade to v12" is not an acceptable answer to a team that is contractually unable to. Publish a support window The common policy is current plus two majors : Version Status What it gets Cadence --- --- --- --- v12.x Active Features, fixes, everything Continuous v11.x Maintenance Critical bugs, accessibility, security Every two weeks v10.x Extended Security and production blockers only On demand v9.x and below End of life Nothing — At roughly two majors a year, that is 12–18 months of coverage. Two things make this policy real rather than decorative: Publish it before anyone needs it. A team choosing to freeze on v10 needs to know in advance what they are giving up. Discovering the support window during an incident is how trust is lost. Make the effort visible. Every backport costs the platform team time. If nobody sees that cost, "just support it a bit longer" sounds free, and the window silently extends to forever. Branch layout Fixes land on first, always. Backporting forward is a merge; backporting backward is a cherry-pick you can review. Fixing an LTS branch first and forward-porting is how a fix gets lost. Automate the backport Manual cherry-picking across three branches is tedious and gets skipped under pressure. Label-driven automation: Two deliberate choices. records the original commit in the message, so you can always trace a backport to its source. And a conflict opens an issue assigned to the original author rather than failing silently — the person with the context does the work, and nothing gets quietly dropped. Backport pull requests run the full gate suite from Chapter 8. An LTS branch with a lower bar is how you ship a regression to the team least able to absorb one. What gets backported Write this down too, because "critical" is otherwise decided per incident by whoever is loudest: Change v11 (maintenance) v10 (extended) --- --- --- Security advisory ✅ ✅ Data loss or corruption ✅ ✅ Accessibility blocker ✅ ✅ Crash or broken core flow ✅ ✅ Visual bug, cosmetic ✅ ❌ Performance improvement ❌ ❌ New feature ❌ ❌ Refactor ❌ ❌ The temptation is always to backport one more thing. Every exception makes the next one easier to justify, and eventually you are maintaining three active branches with three release cadences — which is roughly three times the work for a platform team that was sized for one. Keeping the cost down Chapter 8's cost techniques apply, with LTS-specific adjustments: Run the heavy suites on backport pull requests only , never on a schedule for a branch nobody is changing. Cache per branch. Each LTS branch has a different dependency tree; a shared cache key thrashes. Reduce the matrix for extended support. On v10, run unit tests and the default-theme visual suite. Full theme and width matrices are for . Pin the toolchain per branch. An LTS branch on Angular 20 needs its own Node and Playwright versions. Do not let a toolchain bump break a branch you are not otherwise touching. End of life When a version leaves the window, say so — in several places, in advance. 60 days before: announce in the release notes, in the channel consumers use, and directly to the tech leads of any application still on that version. You know who they are, because your dependency tooling can tell you. On the day: deprecate the packages in the registry so the warning appears at install time: Ongoing: ship a lint rule teams can enable in their own repositories that fails when the installed version is out of support. Opt-in, so it is a service rather than an imposition. An end-of-life date that passes without anything happening teaches everyone that the policy is decorative. "But I thought supporting old versions was just being helpful" It is helpful, which is what makes the trap hard to see. Nobody sets out to support five majors; they say yes to one reasonable request at a time. Three costs accumulate, and only the first is obvious. Every backport is a fresh integration. A fix written against v12's internals may not apply to v11 at all — the Chapter 4 rewrite means the component's structure is different. So it is not a cherry-pick, it is a reimplementation, with its own review and its own test run. The work is not proportional to the fix; it is proportional to how far the branches have diverged. Unlimited support removes the reason to upgrade. This is the counterintuitive one. If v10 gets security fixes indefinitely…