Long-Term Support (LTS): Stability Over New Features

WHY IT EXISTS Production systems demand stability. Constantly upgrading to the latest software version introduces risk, requires extensive re-testing, and can break dependencies. A long-term support policy creates a predictable, stable target for systems that cannot afford to be in a constant state of flux, allowing businesses to operate with confidence.

THE MENTAL MODEL Think of an LTS release like a specific model year of a reliable car, say, a 2020 Toyota Camry. The manufacturer (the software maintainer) promises to provide spare parts (security patches) and fix major recalls (critical bugs) for that 2020 model for many years, even as they release the 2021, 2022, and 2023 models with new features. You don't get the new features, but you get guaranteed maintenance on the version you trust.

HOW IT WORKS A software project designates a specific version (e.g., version 18.x) as an LTS release. While development continues on newer versions (19.x, 20.x), a dedicated team backports critical fixes to the LTS branch. This means a security vulnerability found in version 20 might be patched and released as version 18.x.1. The support period is pre-defined, often lasting several years, after which the version reaches its "end-of-life" (EOL) and is no longer supported.

WHEN TO USE IT Choose an LTS version for production servers, enterprise applications, and critical infrastructure. Use it when stability, security, and predictability are more important than having the latest features. It's the default choice for systems where "if it ain't broke, don't fix it" is a guiding principle.

WHEN NOT TO USE IT Avoid LTS if you are a developer who needs the latest APIs, performance improvements, or language features. For personal projects, development environments, or applications where you can upgrade frequently and easily, the latest stable (non-LTS) release is often a better choice. Sticking to an old LTS for too long can also lead to a massive, painful upgrade when it finally reaches end-of-life.

ONE CANONICAL EXAMPLE Node.js has a well-defined LTS policy. Even-numbered releases (e.g., Node.js 18, 20, 22) are designated as LTS candidates. After an initial six months as the "Current" release, they enter a multi-year "Active LTS" phase for bug fixes and security patches, followed by a final maintenance phase. This gives developers a predictable, stable window to run their applications on a supported version of the Node.js runtime.