guides

LTS stands for Long Term Support, and it is one of the few pieces of release jargon that means exactly what it says. An LTS version is a release line that will keep receiving security and bug fixes for a period announced in advance, instead of being superseded the moment the next version ships.

What LTS actually promises

The promise is a date, not a quality. An LTS release is not necessarily more stable at the moment it appears, and it is certainly not more featureful. What it gives you is a support window you can plan against: you know when the patches stop, and you know it before you deploy.

That distinction gets lost constantly. Teams pick an LTS version believing they have picked the safe one, then run it for years without ever looking at the end-of-life date. An LTS release three months from EOL is a worse choice for a new project than a non-LTS release that has just shipped, because the clock you were relying on has almost run out.

Most LTS lines also have two phases. The active phase still accepts backported improvements. The maintenance phase accepts critical fixes and security patches only. Both count as supported, and they are very different places to be.

How the big projects define it

The rules differ per project, and reading the actual policy takes about two minutes and saves months. Three of the most common:

• Node.js - even-numbered majors only, roughly 30 months of support from release
• Ubuntu - every two years in April, five years of standard support, extendable with Ubuntu Pro
• Java - specific feature releases designated LTS, on a two-year cadence since Java 17

Node.js is the one developers meet first. Only even-numbered major versions become LTS. A major starts as Current, and if it is even-numbered it moves to Active LTS and then to Maintenance, adding up to roughly thirty months of support from release. Odd-numbered majors never become LTS at all, which is why running Node 21 in production was never the plan.

Ubuntu ships an LTS every two years, in April of even years, with five years of standard support for desktop and server; the Ubuntu Pro subscription extends that window considerably for those who need it. Interim releases in between get nine months, which is fine for a laptop and rarely right for a server. Java takes a third approach: Oracle designates specific feature releases as LTS, and since Java 17 that has settled into a two-year cadence.

What you give up

The cost of LTS is paid at migration time, and it is real. A project that follows every release moves in small steps and absorbs breaking changes as they arrive. A project that hops between LTS versions saves that effort for years and then pays it in one lump, upgrading across everything that changed in between.

There is a second cost that is easier to miss. Staying on an old LTS means your dependencies start dropping you first. Libraries set their minimum supported runtime by what is current, not by what is still receiving security patches, so you reach a point where the platform is supported and the ecosystem around it is not. That is usually the real deadline, and it arrives before the official one.

The date that actually matters

So the practical rule is simple, and it is not the one people follow. Do not ask whether a version is LTS. Ask when its support ends, and compare that date to how long this project will realistically live untouched.

If the answer is that support ends before your next planned upgrade window, you have not chosen stability. You have chosen an unpatched production system with a date on it, and the date is already in the calendar.