For production services, standardize on a long-term support (LTS) release of each runtime and move between LTS lines on a calendar. Current or short-term releases suit experiments and tooling. The projects themselves publish rules that point this way, but the details differ, so record each runtime's own terms.
What the projects say
Node.js. The release page says major versions enter a Current status for six months, and that production applications should only use Active LTS or Maintenance LTS releases. It describes LTS as typically guaranteeing that critical bugs are fixed for a total of 30 months. It also says that starting with Node.js 27, the release cycle becomes annual and every major version moves to LTS after its six-month Current phase. So the old habit of treating odd numbers as short-lived changes soon.
Java. Oracle's roadmap names Java SE 8, 11, 17, 21 and 25 as LTS releases. It says Oracle intends to make future LTS releases every two years and names Java 29 in September 2027 as the next planned LTS. For non-LTS releases, it says they are treated as a cumulative set of enhancements of the latest LTS and are superseded when a new feature release appears.
.NET. The support policy table labels .NET 10 as LTS with end of support on 14 November 2028, .NET 8 as LTS and .NET 9 as STS (standard term support), both ending on 10 November 2026. The gap between the two labels shows up in the dates: the STS release ends on the same day as the older LTS one. See LTS or STS: which .NET release to choose.
Ubuntu. The release cycle page shows LTS releases with standard security maintenance of five years, for example May 2027 for 22.04 and May 2029 for 24.04.
A decision guide
| Situation | Suggested choice |
|---|---|
| Customer-facing production service | Latest LTS you can test fully |
| Internal tool with a small user base | LTS, or current if the owner commits to upgrading often |
| Prototype or experiment | Current, with an expiry date on the experiment |
| Library you publish | Test on all supported LTS lines you claim to support |
| Build and CI images | Match production, then newer in a separate job |
Two rules keep this honest. If you choose a non-LTS release, write down the upgrade date in advance. And do not choose the oldest LTS just because it is stable: its remaining window may be shorter than the next LTS's full window.
Standardizing without freezing
A single version across the company is rarely realistic. Aim for a short list: one primary LTS and one next LTS under test. When the primary reaches the last year of support, promote the next one. This is the idea behind planning a runtime upgrade before end of life.
Record the policy as data, not a wiki page. For each runtime: the approved versions, the date each approval ends, and the owner who can grant exceptions. Check it against the inventory to find services outside the list.
What to record
- Approved runtime lines and their end dates.
- The date of the last review.
- Services outside the approved list, with owner and target date.
- The source page for each runtime's rules.
Runtime support windows compared gives a side-by-side view of the windows.
Try it yourself
Click through it at your own pace, or open it full screen. Look at the version column, then compare it with your approved list.
Where Safeguard fits
Safeguard's SBOM and dependency scanning shows what versions you actually run, and its policies and gates can encode the approved list. The free scan is at gold.safeguard.sh/scan.
Quick check
Is LTS always safer than current?
It gives a longer window of fixes, which is usually better for production. It is not a guarantee about any specific bug.
Is the newest LTS always the right pick?
Pick the newest LTS you can test fully. A newer line gives the longest remaining window.
Sources
Last reviewed: 19 October 2026.
