Node.js has announced a significant change to how it ships major versions, starting with Node.js 27 in October 2026. One major release per year, every release becomes LTS, and a new Alpha channel replaces the early-testing role that odd-numbered releases previously served.
The current model ships two majors per year. Even-numbered releases (18, 20, 22) go to Long-Term Support; odd-numbered ones (19, 21, 23) exist for six months and then reach end-of-life without LTS status. In practice, most production deployments skip odd releases entirely and wait for the next even one. The Node.js team has the telemetry to confirm this; adoption numbers for odd releases are consistently low.
That made odd releases a maintenance burden with limited payoff: real work, minimal uptake. For an open-source project sustained by volunteers, that imbalance matters.
What Changes
Starting October 2026, the release cycle looks like this:
- Alpha (6 months, October to March): A new phase that replaces the early-testing role of odd releases. Semver-major changes are allowed here. Aimed at library authors and CI pipelines, not production use.
- Current (6 months, April to October): The stabilization window where breaking changes stop landing.
- LTS (30 months): The long-term support period, same duration as before.
- Total support per release: 36 months.
The odd/even distinction disappears. Node.js 27 will be the first release where every version is destined for LTS.
The Alpha Channel Is Worth Understanding
The Alpha phase deserves attention beyond the headline. It is signed and tagged, tested through CITGM (Canary in the Goldmine), and designed for the people who need to catch breakage early: package maintainers, library authors, teams running compatibility suites. The six-month window before Current gives the ecosystem real time to respond to semver-major changes before they stabilize.
This is a cleaner feedback loop than the old model, where odd releases served the same purpose informally, but with the added confusion of being technically production-ready versions that most people simply avoided.
The Broader Point
Release cadence decisions in open-source projects are rarely just engineering choices. They reflect the capacity of the people doing the work. Halving the number of concurrent release lines means maintainers can focus more attention on fewer things, which generally produces better software.
For most Node.js users, this change is invisible in practice. If you were already waiting for LTS before upgrading production systems, your workflow does not change. The project is now designed around that reality, with a cleaner process for the library authors and tooling maintainers who do need early access to what is coming.