What is LTS? —
long-term support, and the trap inside it.

"Just use the LTS version" is the most common piece of software lifecycle advice ever given — and one of the least explained. What exactly are you being promised when a release is stamped Long-Term Support? Who's promising it, for how long, and what happens when even the long term ends? This guide covers how LTS actually works across the major ecosystems, why vendors invented it, and the planning mistake that catches almost everyone.

What LTS actually promises

An LTS release is a version the maintainer commits to supporting — security patches and critical bug fixes — for a defined, published, longer-than-normal window, without forcing you to absorb new features or breaking changes along the way. Three parts of that sentence carry all the weight:

• Defined and published. The end date is known on day one. LTS is not "supported for a long time"; it's "supported until this specific date." That date is the single most useful piece of planning information in your stack — it's the entire reason this site exists.
• Security fixes, not features. During the LTS window you get patches, not progress. The version is deliberately frozen so that applying an update is boring — which is exactly what production systems want.
• Longer than normal — not forever. Typically two to five years, versus months for a standard release. Then it ends, on schedule, regardless of how many people still run it. Windows of every length close; LTS just tells you when.

Why vendors invented it

LTS is a truce between two audiences that want opposite things. Developers and the project itself want to ship — new features, better performance, breaking changes that clean up old mistakes. Operators want nothing to change, ever, except security fixes. Without LTS, projects either move too slowly (frustrating development) or too fast (leaving production users stranded on unpatched versions because upgrading is disruptive).

The LTS model resolves this by splitting the release train: a fast track for people who want the newest, and designated stable checkpoints with long patch windows for people running businesses. It also concentrates the ecosystem — when most production users sit on the same LTS lines, framework authors, security researchers, and vendors all test against the same versions, which makes those versions genuinely safer. That's why "use the LTS" is usually right — and why understanding its expiry is non-negotiable.

The LTS rhythms of major ecosystems

Every ecosystem tunes the model differently. Knowing the rhythm of yours is the difference between planned upgrades and emergency ones:

Node.js — even numbers only

Even-numbered Node.js releases (18, 20, 22, 24…) enter LTS and receive roughly 30 months of total support. Odd-numbered releases are short-lived experiments — they exist to preview features and are retired within months. Production on an odd Node version is a scheduling accident waiting to happen.

Java — the two-year checkpoint

Since the release cadence changed, a new Java LTS arrives every two years (17, 21, 25), with non-LTS versions shipping every six months and dying when the next one arrives. The twist: how long an LTS lasts depends on whose build you run — Oracle, Temurin, Corretto and others publish different support windows for the same Java version. In the JVM world, LTS is a property of the vendor, not just the version.

Ubuntu — the five-year workhorse

An Ubuntu LTS lands every two years (20.04, 22.04, 24.04) with five years of standard support, extendable to roughly a decade with paid Expanded Security Maintenance. The interim releases get just nine months — one of the sharpest LTS/non-LTS gaps anywhere.

.NET — LTS and STS, explicitly labeled

Microsoft alternates .NET releases between LTS (three years — .NET 8) and STS, "Standard Term Support" (18 months — .NET 9). Same framework, same quality, radically different planning horizon; the label is right there in the release notes and routinely ignored.

Frameworks and libraries — shorter than you think

Application frameworks run tighter windows: a Django LTS gets about three years, a Spring Boot minor roughly a year of open-source support, an Angular major about 18 months. And in the library world, "LTS" sometimes means a paid program — Jackson designates open LTS branches, while vendors like Tiny sell LTS agreements for TinyMCE after open-source support ends. Always check what the word means in the ecosystem you're reading.

The LTS trap: stability is not immortality

Here is the mistake that fills remediation backlogs: teams hear "LTS" as "solved" and stop tracking the date. The stability is real — for the window. But choosing an LTS at its release gets you the full window; adopting it two years in gets you the remainder, and organizations routinely standardize on an LTS just as it enters its final year.

The second half of the trap: because LTS versions are stable for years, the skills and context for upgrading atrophy. The team that deployed on the LTS has moved on; nobody remembers the app's quirks; and the eventual jump spans multiple major versions at once — the hardest possible upgrade, scheduled by an external deadline. As we covered in CVEs by stack layer, that's precisely how frameworks and runtimes end up frozen past EOL, where every new CVE becomes permanent.

The other trap: non-LTS releases in production

The inverse mistake is quieter: a developer starts a project on the newest release — Node 23, .NET 9, a non-LTS Java — because it's what the tutorial used or what shipped that week. The project goes to production, and its support window turns out to be measured in months. Nothing is wrong with non-LTS releases; they're for people who upgrade continuously. The failure is deploying one without pricing in that treadmill. If your organization upgrades annually, only LTS rhythms fit.

How to actually plan around LTS windows

• Record the end date at adoption. The day you choose a version, its EOL date goes in the roadmap — not a scanner finding three years later. (Our catalog publishes the windows for 479 products; the API feeds them into your own tooling.)
• Budget the migration at half-life. When an LTS window is half over, the successor exists and is proven. Migrating then is a choice made in calm; migrating in the final quarter is a deadline made in panic.
• Prefer skipping one LTS ahead, never two behind. Consecutive-LTS upgrades are documented, tested paths (20.04 → 22.04, Java 17 → 21). Multi-generation jumps are where upgrades become rewrites.
• When the window closes anyway — because budgets and legacy apps are real — make the overstay explicit: risk-register entry, compensating controls, and if needed extended lifecycle support as a paid bridge, not silent drift.

LTS is the best deal in software operations: years of boring, patched stability in exchange for one obligation — knowing when it ends. Keep the date, and the model works exactly as advertised.