LTS, short for long-term support, is a designation for a software release that the maintainers commit to support with security updates and critical bug fixes for an extended, published period, usually several years, while new features go into other releases. In the software lifecycle, LTS defines a stable branch that organizations can deploy and keep running without frequent major upgrades.
An LTS release is a promise about maintenance, not about quality alone. It tells administrators, developers and vendors how long a version will remain safe to use and when they must plan a migration before the release reaches its end of life. Operating systems, programming language runtimes, frameworks, databases and office suites all use the concept.
How long-term support works
An LTS release is created by branching a version off the main development line and freezing its feature set. From that point, maintainers only backport selected changes to the branch: security patches, fixes for serious defects, and sometimes hardware enablement or compatibility updates. Behavior visible to users and integrators is meant to stay stable.
Backporting is the core of the mechanism and also its main cost. A fix written for the current code must be adapted to older code that may have diverged significantly. As the gap widens over the years, each backport becomes more expensive and riskier, which is why every LTS period eventually ends.
Most projects publish an LTS schedule in advance: when an LTS version appears, how long it receives full maintenance, how long it receives security-only fixes, and its final end-of-life date. Predictability is the main value, because it lets organizations align upgrades with budgets, audits and hardware refresh cycles.
Typical support phases and durations
LTS periods are usually divided into phases with decreasing scope. The names vary between projects, but the pattern below is common across operating systems, runtimes and frameworks.
| Phase | What is delivered | Typical length |
|---|---|---|
| Active support | Bug fixes, security fixes, minor improvements | Months to about 2 years |
| Maintenance support | Security and critical fixes only | 1 to 3 years |
| Extended or paid support | Security fixes for subscribers | Several additional years |
| End of life | No further updates | Permanent |
Concrete durations differ widely. Ubuntu LTS releases appear every two years with five years of standard maintenance and optional paid extension. Node.js designates even-numbered major versions as LTS with roughly 30 months of total support. Some Java distributions support LTS versions for eight years or more. The release notes of each project remain the authoritative source for exact dates.
LTS compared with other release types
LTS is best understood alongside the other release categories in the software lifecycle. Each balances novelty against stability differently and serves a different audience.
| Release type | Feature changes | Support length | Typical user |
|---|---|---|---|
| LTS release | Frozen after release | Years | Servers, enterprises, embedded devices |
| Standard or current release | New features regularly | Until the next release or slightly longer | Developers, enthusiasts |
| Rolling release | Continuous | No fixed versions | Users who want the latest software |
| Release candidate | Final testing before release | Short, until final version | Testers |
| Nightly build | Every change | None | Contributors |
LTS interacts with semantic versioning in a straightforward way: an LTS line usually stays on one major version and receives only patch and occasionally minor releases. It also interacts with deprecation, because features announced as deprecated in one release are often kept until the next LTS so that long-lived installations have a full cycle to migrate.
Choosing between LTS and newer releases
Selecting an LTS release is a decision about risk tolerance, upgrade capacity and feature needs. The table offers typical guidance.
| Situation | Recommended choice | Reason |
|---|---|---|
| Production servers | Current LTS | Stable behavior and predictable patches |
| Embedded or industrial devices | LTS with longest support | Field updates are costly |
| Software development workstation | Current or recent LTS | Access to new tools and APIs |
| New hardware just released | Latest release or LTS point update | Needs newer drivers |
| Regulated environment | LTS with paid extended support | Audits require vendor-backed patching |
A practical rule used by many teams is to adopt a new LTS only after its first point release, which collects early fixes, and to plan the migration away from the old LTS at least six to twelve months before its end of life.
Limitations and common misconceptions
LTS reduces change but does not eliminate it. Several misunderstandings lead to avoidable security and compatibility problems.
- LTS does not mean bug-free. It means that serious bugs will be fixed during the support period; minor issues may remain unaddressed.
- Not every component is covered equally. In operating systems, only the core packages may receive full LTS treatment, while community packages get less attention.
- Installing updates is still required. An LTS release without regularly applied patches is no safer than an unsupported one.
- Staying too long creates a cliff. Skipping several LTS generations turns a routine upgrade into a large migration project.
- Dependencies have their own lifecycles. An application on an LTS runtime may still rely on libraries that reach end of life sooner.
Put simply
LTS means that the makers of a program promise to keep it safe and working for a long, fixed time. That time is often several years. Users do not have to accept big changes during it. It is a bit like a car with a long service guarantee. The car gets no new features, but repairs and safety recalls are covered until a known date.
People choose LTS when reliability matters more than novelty. They mark the end date in the calendar and move to the next version in good time.
In practice
An online retailer runs its web shop on servers using an LTS edition of a Linux distribution and an LTS version of its application runtime. The operations team applies security patches monthly, usually without restarting more than individual services, and no update changes how the shop behaves.
Eighteen months before the runtime reaches end of life, the team tests the shop on the next LTS version in a staging environment. They find two deprecated functions in their code, replace them, and migrate production during a quiet sales period. The result is an upgrade completed calmly and on schedule, instead of an emergency migration after security updates have stopped.