Node.js Overhauls Release Cadence: One Major Version per Year, All LTS

Announcement

Starting with Node.js 27 the project will publish only one major version per year, and every released version will become an LTS (Long‑Term Support) release.

Problems with the old model

For the past decade Node.js used an “even versions become LTS, odd versions do not” policy (e.g., Node 20 LTS, Node 21 not, Node 22 LTS). In practice most developers and enterprises avoid odd versions because they lack long‑term support and reach end‑of‑life quickly. This created three core issues:

Resource waste : maintenance effort spent on odd versions with very low adoption.

Newcomer confusion : the even/odd distinction is not intuitive for beginners.

Maintainer pressure : volunteers had to keep 4‑5 release lines alive, making backporting and security‑patch work increasingly difficult.

New release model

The new cadence consists of four sequential phases:

Alpha – October to March (6 months). A preview channel that allows breaking changes. Builds are signed, tagged releases (not nightly snapshots) and are tested with the CITGM (Canary in the Goldmine) tool, which runs the test suites of popular open‑source packages to detect compatibility breaks before the official release.

Current – April to October (6 months). The official release entering a stable period.

LTS – Starts in October and lasts 30 months. Provides long‑term support and receives security fixes.

EOL – After the LTS period ends. No further maintenance.

A version receives a total of 36 months of support from its Current release to EOL.

Version numbers align with years

The major version number now matches the calendar year: Node.js 27 will be released in 2027, Node.js 28 in 2028, and so on, making it easy to infer the release year from the version number.

Alpha channel explained

The Alpha channel runs from October to March each year. It is intended for library authors to run compatibility tests in CI; it is not meant for production use.

Suitable for : library authors testing compatibility early.

Not suitable for : production environments.

Impact on different developers

If you only use LTS versions (the majority), the change is almost transparent: support periods remain unchanged and the upgrade path becomes clearer because every new version is LTS.

If you are a library author , add the Alpha version to your CI matrix to catch compatibility issues early.

If you are a Node.js contributor , the reduced number of active release lines lowers backport workload and security‑patch pressure.

Future release timeline (10‑year view)

Node.js 27: 2026.10 Alpha → 2027.04 Release → 2027.10 LTS → 2030.04 EOL
Node.js 28: 2027.10 Alpha → 2028.04 Release → 2028.10 LTS → 2031.04 EOL
Node.js 29: 2028.10 Alpha → 2029.04 Release → 2029.10 LTS → 2032.04 EOL
Node.js 30: 2029.10 Alpha → 2030.04 Release → 2030.10 LTS → 2033.04 EOL

Additional details

During the GitHub issue discussion an early proposal suggested shortening LTS from 30 months to 24 months, but the final plan retained the 30‑month support period, showing community feedback influencing the decision.

The V8 engine update schedule remains unchanged; each new Node.js release ships with a V8 version that was stable roughly six months earlier.