Do not adopt a new release the day it ships, and do not wait until the old one expires. A common rule is to move production to a long term support (LTS) release after its first few patch releases and finish before the old release reaches end of life. That leaves a window of months on each side.
How LTS and standard releases differ
Vendors split releases into two kinds. Long term support versions get a longer period of fixes. Standard or Current versions get a short one.
| Project | Long term | Standard or current | Source of the rule |
|---|---|---|---|
| .NET | LTS, three years | STS, two years | Microsoft support policy |
| Node.js | Even numbered lines, LTS | Odd numbered lines are not LTS | Node.js release page |
| Django | LTS every few years, longer coverage | Feature releases, shorter | Django download page |
| PHP | Every release, four years | No LTS split | php.net |
Node.js advises that production applications should use Active LTS or Maintenance LTS releases. .NET has a notable example of the tradeoff: .NET 8 and .NET 9 both end on 10 November 2026, because the standard release is only supported two years while the LTS before it is supported three.
A timing rule you can state
- Never run production on a Current or standard release unless you accept a move every year or so.
- For LTS, begin testing in staging when it ships.
- Move production after the first patch releases settle, often a few months in.
- Finish at least one quarter before the old line ends.
This leaves a long overlap in which both lines are supported, so a delay in one project does not push you into an unsupported state.
What to weigh
- Library readiness. If key packages do not support the new release yet, wait for them.
- Regulatory or customer constraints. Some buyers ask for supported versions only.
- Team capacity. Annual upgrades are easier when they are small and routine.
- Risk appetite. Early adopters get fixes and features sooner and meet more bugs.
Small steps beat big jumps
Teams that upgrade every LTS find each move small. Teams that skip two lines face large breaking changes, and often discover that a dependency was abandoned in between. Treat the upgrade as maintenance in the roadmap, not a special project.
Write it down
A one page policy helps: which release channel you run, how soon after release you start testing, and the latest allowed date to leave a line. Link it from your engineering standards and check it in the same register as your end-of-life dates. See how to track support windows.
Quick check
Is it unsafe to use a Current Node.js release?
Not unsafe in itself, but the project advises production apps to use LTS lines, and Current lines have a short support life.
Why do two .NET versions end on the same day?
LTS gets three years and STS two years, and the dates align on Patch Tuesday in November 2026.
Where Safeguard fits
Safeguard's dependency scanning shows which of your projects run which runtime lines, which helps you apply a policy like this across an estate. See the free scan.
Sources
Last reviewed: 19 October 2026.
