Stop backporting to a release line when you can no longer test it properly, when a fix would need a pile of prerequisite changes, or when very few users remain on it. Announce the end date well ahead, publish the supported versions, and give users a clear upgrade path.
Why you must end somewhere
Every supported line multiplies the work of each security fix: another branch, another conflict, another test run, another release. Past a point, quality of the fixes on old lines drops, and a poorly tested backport can do more harm than none. The Kubernetes project shows one answer on its patch releases page: it states a patch release cadence, and lists the branches that are currently active for patch releases, with older ones recorded as non-active history.
Signals that a line should end
| Signal | Meaning |
|---|---|
| Backports need many prerequisite commits | The line is turning into a new feature release |
| Test infrastructure for that line is gone | You cannot prove the fix |
| Toolchain or platform it needs is out of support | Building it is itself a risk |
| Few users and a simple upgrade exists | Support cost outweighs benefit |
| A newer line has been stable for a while | Users have somewhere safe to go |
Steps
- Publish a support policy: how many lines you maintain and for how long after a new one ships.
- Pick the end date for the old line and announce it in the release notes, the docs and any security page.
- Warn again closer to the date, using the channels customers watch.
- In the final release for that line, say plainly that it is the last and what to upgrade to.
- After the date, label the line end of life in your docs and your security policy file.
- For a later vulnerability, say whether the old line is affected, even if you will not fix it. Users deserve to know.
Handling hold outs
Some customers will not move. Offer a clear upgrade guide and, where your business model supports it, a separate arrangement. Do not quietly keep patching with no process. If you cannot support the line, say so and let the customer make an informed choice.
What to put in the policy
Write the number of lines, the support length, what qualifies for a fix on an older line (security issues of a certain severity, for example) and who decides exceptions. The Linux stable rules are a good model for being explicit: they list what is accepted and what is not, so nobody argues from feeling.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings can be grouped by component, which helps you see how many of your findings sit on lines you plan to retire.
Safeguard's dependency inventory shows which versions of your own components and third party packages are in use, which can inform an end of support decision. A free scan is at gold.safeguard.sh/scan.
Quick check
How long should an old line be supported?
It depends on your users and your capacity. Pick a length you can actually test and fund, then publish it.
Should I tell users if an unsupported line is affected?
Yes. Say it is affected and that no fix will ship, so users can decide what to do.
Sources
Last reviewed: 19 October 2026.
