Backport security fixes to an old major version only for a window you state in advance, such as the previous major for a set period. Without a stated window, either you maintain every old line forever or teams do not know whether they are covered. Publish the policy and the end dates.
Why the question comes up
A design system ships a new major with breaking changes. Large apps rarely migrate on day one, so for months two or three majors are in use. When a dependency inside the library gets a security advisory, the fix must go into each supported line, or the apps on old lines stay exposed.
Semantic versioning, as described at semver.org, says a patch release is for backward compatible bug fixes, a minor adds functionality compatibly, and a major is for incompatible changes. That structure is what makes a backport possible: a patch on the old major can carry the dependency bump without forcing API changes. Where a fix cannot be made without a break, see can a security fix be a breaking change in semver.
Choosing a support policy
| Policy | Pros | Cons |
|---|---|---|
| Latest major only | Cheapest to maintain | Apps on older majors are left exposed |
| Latest and previous major, fixed window | Predictable, realistic for migrations | Two lines to patch and test |
| Long term support line for selected majors | Fits slow moving apps | Real ongoing cost, needs an owner |
| No policy | None | Surprises during incidents |
Most design system teams land on the second option. The window length is a business decision, so write it down and keep it short enough to motivate migration.
What a backport involves
- Branch from the last release tag of the old major.
- Apply the minimal dependency bump, not unrelated changes.
- Run the same gates: unit tests, visual tests, a dependency scan, a build of a sample app on that major.
- Publish a patch release on the old major, with the right dist tag so it does not become the default install. The behavior of tags is explained in npm dist-tags: what latest means for your installs.
- Announce it with the adoption deadline for the affected apps.
What to say to teams outside the window
Be direct. Tell them the major is out of support, which advisories affect it, and what the migration path is. Offer a mitigation if there is one. If an app cannot move, ask the owner to record a risk acceptance with an end date, rather than letting the gap sit unnoticed.
Keep the cost visible
Each supported line multiplies testing. Track how many apps remain on each major, using the routine in how do you find which apps still use an old design system version. When the last app leaves a line, retire it and say so.
Safeguard's policies can flag applications that still resolve a vulnerable version of a library after a patch exists, which helps decide when a backport window should close. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Does a backport need a new minor version?
No. A patch release on the old major is the right shape for a compatible fix.
What if the fix cannot be done without a breaking change?
Say so in the advisory, offer a mitigation, and set a migration deadline for the affected apps.
Sources
Last reviewed: 19 October 2026.
