Node.js Is Cutting to One Major Release Per Year, and the Data Backs It Up

The Node.js project just announced a significant change to its release model: starting with Node.js 27 in October 2026, the project will publish one major release per year instead of two. Node.js 26, shipping in April 2026, is the last version under the old model.

The reasoning is straightforward and grounded in ten years of real usage data. Odd-numbered releases, which were never LTS candidates, saw minimal adoption. Most users, especially in enterprise environments, waited for even-numbered LTS versions and skipped the intermediate ones entirely. Maintaining four or five active release lines simultaneously put unsustainable pressure on volunteers who handle security backporting across all of them.

So the team is cutting the release lines, keeping what people actually use.

What the New Schedule Looks Like

Each version now moves through three phases:

• Alpha (6 months, October to April): Semver-major changes are allowed. Signed and tagged releases, but not suitable for production. This is where the ecosystem stress-tests breaking changes.
• Current (6 months, April to October): Stabilization phase, the new stable release.
• LTS (30 months): Long-term support with security fixes, the same as before.

Total support per version comes to about 36 months, which is comparable to what LTS versions received under the old model. The April release and October LTS promotion dates stay the same.

Version numbers will also align with the calendar year of their initial release, so Node.js 27 ships in April 2027, Node.js 28 in April 2028, and so on.

The Alpha Channel Is the Real Change

The odd-numbered releases served a testing purpose that the new Alpha channel now takes over, but with an important difference: breaking changes are permitted during Alpha. Under the old model, the distinction between odd and even releases was subtle enough that new developers consistently misunderstood it. An explicit Alpha label is clearer about what you are signing up for.

For library authors, this matters quite a bit. If you only test against LTS releases, you will not encounter breaking changes until they have already shipped in a Current release. The expectation is that library maintainers integrate Alpha builds into their CI pipelines and report issues before they reach production users. That is a reasonable ask, and it gives the ecosystem a defined window to surface compatibility problems.

What Does Not Change

Users running LTS releases will notice the version numbering shift, but the support duration and overlap windows stay roughly the same. Organizations that already skip every non-LTS release will find their workflow mostly unchanged, just with less noise in the version number stream.

The quality standards, CITGM testing, and V8 adoption cycle are all preserved. Each new Current release will still ship with a V8 version no more than six months old.

A Reasonable Evolution

This is a good call. The odd/even model made sense when Node.js was moving fast and needed a faster feedback loop from production users. Ten years in, with a stable ecosystem and predictable LTS adoption patterns, maintaining two release lines per year added overhead without adding much value to the people actually running Node.js in production.

The Alpha channel preserves the ecosystem testing function while being honest about what that phase is for. Library authors who care about compatibility now have a clearer signal: watch the Alpha, file issues early, and do not wait for LTS to find out that something broke.

Node.js 26 is the last of the old model. Everything after that follows the new annual cadence.