The Node.js project is making a significant change to how it ships software. Starting with Node.js 27.x in October 2026, the team is moving from two major releases per year to one, eliminating the odd/even versioning distinction that has confused developers for years.
What’s Actually Changing
The current model produces two major versions annually: an odd-numbered “Current” release in October for early adopters, followed by an even-numbered LTS release in April. The odd releases exist mostly as a stabilization period before the LTS. In practice, most users skip the odd versions entirely, and organizations running production systems tend to wait for LTS before upgrading.
Under the new model:
- One major release per year, in April, going straight to LTS in October
- Every release becomes LTS, no more odd/even distinction
- An Alpha channel replaces odd-numbered releases for early testing
- Version numbers align with the calendar year (27.x in 2027, 28.x in 2028)
The LTS window stays at 30 months, so total supported lifetime remains the same. Migration windows are preserved. Nothing changes about quality standards or the V8 adoption cycle.
The Alpha Channel
This is the most interesting part of the proposal. Rather than shipping a full-blown numbered release as an early-testing vehicle, the team is introducing a formal Alpha channel that sits between nightly builds and Current releases.
Alpha releases are signed and tagged, run through CITGM (Canary in the Goldmine), and allow semver-major changes. They carry more guarantees than nightly builds but are explicitly not for production. The release team determines the timing and frequency based on how many changes have landed.
Library authors are the primary audience here. If you maintain a package with broad Node.js compatibility requirements, integrating Alpha releases into your CI pipeline gives you early visibility into breaking changes before they hit a stable release and affect your users.
Why This Matters
The volunteer sustainability argument is the one that carries the most weight. The Node.js release team currently manages security patches and backports across four or five active release lines simultaneously. That is a real maintenance burden, and it falls on a relatively small group of people.
The data backs the decision: odd-numbered releases see minimal adoption. Most developers either use the latest LTS or whatever version their deployment platform provides. Shipping two major versions per year when one of them goes largely unused is overhead that doesn’t serve users well.
From a dependency management perspective, this simplifies things. Fewer active lines means clearer upgrade paths. For anyone running Node.js in production, the guidance has always been to stay on LTS; this change aligns the official release model with how people actually use the runtime.
Node.js 26, releasing in April 2026, is the last version under the old model. It enters LTS in October 2026 and reaches end of life in April 2029. After that, the new schedule takes over.
The proposal is not final and the team has an open discussion at nodejs/Release#1113 if you want to weigh in. But the direction is clear, and given how the community actually uses Node.js, the consolidation seems long overdue.