Give security fixes to the latest release line always, and to the previous major version only until its last consumer migrates or a published cutoff date passes. Older lines get no fixes, and the library owner says so in writing so consumers can plan.
Why a rule is needed
Without a rule, owners either patch everything, which is unsustainable, or patch only the newest line, which strands teams on older majors with known issues. Neither is a decision. It is drift.
The semantic versioning link
The Semantic Versioning specification defines a patch release as one that contains only backward compatible bug fixes, and says a minor version must be incremented when new backward compatible functionality is added or public API functionality is deprecated. Breaking changes need a major. That is why a security fix on an old line is cheap when it can ship as a patch, and expensive when the fix itself breaks the API.
If the only safe fix is breaking, say so plainly and ship it in a new major, with a migration note, instead of hiding it in a patch.
A support window you can copy
| Release line | Security fixes | Notes |
|---|---|---|
| Current major, latest minor | Yes | Default target |
| Current major, older minors | Upgrade to latest minor | Minors are compatible |
| Previous major | Yes, until cutoff date | Published date, ideally 6 to 12 months |
| Anything older | No | Consumers must migrate |
How to pick the cutoff
- Count consumers still on the previous major using your inventory.
- Ask the three biggest or most sensitive consumers what they need.
- Set the date, publish it in the README, and mark old versions as deprecated in your registry. npm documents that deprecation shows a warning to everyone installing the package.
- Review the date quarterly. If a critical consumer will miss it, either help them migrate or extend once, with a new date.
Backport mechanics
Fix on the main branch first. Cherry pick onto the supported release branch. Run the tests of that branch. Tag a new patch version, never rewrite an existing tag, because released contents must not change. Record in the release notes which lines were fixed.
What to tell consumers
State the supported lines in the README, restate them in every security release note, and warn consumers a month before a line ends. For notice templates see how to announce a security release.
Safeguard can help with the inventory side: its SBOM and dependency scanning shows which services pull in a given internal library, and you can run a free scan at gold.safeguard.sh/scan.
Quick check
Do we need to patch every minor version?
No. Minor releases are backward compatible, so consumers can move to the latest minor of their major to get the fix.
What if a consumer cannot leave an old major?
Record a time limited exception with an owner and an end date, and plan the migration. Do not extend support indefinitely.
Sources
Last reviewed: 19 October 2026.
