Node.js Ditches Odd/Even Model, Ships First 27.x Alpha

Node.js is overhauling how it ships major versions. The project has begun phasing out its long-standing odd/even release cadence in favor of a single annual major release, with every one of those releases automatically becoming a Long-Term Support (LTS) line. The change is now underway: the first alpha build under the new model, version 27.0.0-alpha.0.0.0, was published on October 29, 2026.

What is actually changing

For roughly a decade, Node.js has shipped two major versions a year — one in April, one in October — with only the even-numbered release (April) graduating to LTS six months later. Odd-numbered releases (like Node.js 25) were short-lived "Current" branches that most production users skipped entirely.

According to the official Node.js blog post "Evolving the Node.js Release Schedule", published by the Node.js Releasers team, that split is going away. Starting with Node.js 27, the project moves to:

• One major release per year. A single version ships as "Current" each spring instead of two versions a year.
• Every release becomes LTS. There is no more odd/even distinction — the version that used to only exist as a short-lived Current branch now gets the full LTS treatment.
• A new, explicit Alpha phase. Before a version becomes Current, it spends six months as an Alpha channel where semver-major (breaking) changes are allowed to land, specifically so library authors and CI pipelines can test against upcoming breaking changes early.

How the old odd/even model worked

To understand why this is a significant change, it helps to recap the system it replaces. Under the schedule Node.js has used for about a decade, a new major version shipped every six months — April and October. Only the April release (an even number, like 26) was ever promoted to LTS, six months after it debuted as "Current." The October release (an odd number, like 25 or 27 under the old numbering) existed purely as a short-lived Current branch: it never became LTS and was effectively obsolete once the next version shipped.

That meant two different experiences depending on which numbered line you landed on. Pick an even release and you got roughly three and a half years of support (six months as Current, 30 months as Active and Maintenance LTS). Pick an odd release and you got a handful of months before you had to move on — something many teams only discovered after already deploying on it. The Node.js Releasers' post singles this confusion out as one of the clearest signals that the system needed to change.

Why Node.js is dropping the odd/even model

The blog post frames this primarily as a maintainer-sustainability fix, not a feature push. The release schedule has existed largely unchanged since the io.js merger roughly ten years ago, and the project says it no longer matches how Node.js is actually used:

• Odd-numbered releases saw minimal real-world adoption — most teams wait for an LTS line, and plenty of organizations skip odd releases outright.
• The odd/even split is a recurring source of confusion for newcomers trying to figure out which version to install.
• Juggling security backports across four or five concurrently active release lines has become difficult for a volunteer-driven release team. Cutting the number of concurrent lines lets maintainers concentrate effort on the versions people actually run.
• Enterprises consistently asked for more predictability in the upgrade calendar.

The post is explicit that this schedule "is not final and may be amended," with further discussion planned at the Node.js Collaboration Summit; the authoritative, continuously updated record is the schedule.json file in the nodejs/Release repository on GitHub.

The new support windows

Each annual release now moves through three defined phases instead of the old Current-then-maybe-LTS path:

That adds up to roughly 36 months of total support, from a version's first day as Current to its end-of-life (EOL) date — a figure the project says is comparable to the overlap teams get today, even though fewer release lines are active at once.

Node.js 27's timeline under the new model

Node.js 27 is the first release built under this schedule. Based on the dates published in the announcement:

Node.js 26, which became active LTS on October 28, 2026 (see our earlier coverage of Node.js 26 becoming active LTS), is the last release line to run under the old twice-a-year model. Future major versions will follow the new annual cadence Node.js 27 is establishing.

Inside the first 27.0.0 alpha build

The alpha itself, tagged 27.0.0-alpha.0.0.0 and published by Node.js TSC member Rafael Gonzaga, is a pre-release snapshot meant for compatibility testing in CI pipelines, not production workloads. Per the official release notes on nodejs.org, it carries a substantial jump in its JavaScript engine and several semver-major changes:

• V8 engine: upgraded from V8 14.6 (used in Node.js 26) to V8 15.6.75.13 — one of the larger single-step V8 jumps in a recent Node.js release, reflecting the Alpha phase's explicit allowance for breaking engine updates.
• OpenSSL: updated to OpenSSL 4.1.0; the build now requires OpenSSL 3 or later and removes legacy OpenSSL code paths, the bundled FIPS provider build, and OpenSSL engine support.
• npm: bundled npm upgraded to 12.1.0.
• Serialization format change: v8.serialize(), structuredClone(), and postMessage() now use a new internal format that older Node.js versions cannot read back.
• Memory defaults: when --max-old-space-size isn't set, the default heap limit is now half of physical memory, clamped between 256 MB and 4 GB, with Buffer and ArrayBuffer memory now counted against that limit. The release notes recommend setting the flag explicitly going forward.
• WebAssembly and asm.js: asm.js is no longer compiled to WebAssembly, and the --experimental-wasm-* flags have been renamed to --wasm-*.
• Deprecations: the domain module is now runtime-deprecated; the default http keepAliveTimeout changes to 65 seconds; error.stack is no longer resolved through the prototype chain; and several crypto input and digest-encoding checks are now stricter.
• Platform support: Intel-based macOS support is downgraded to experimental in this build.

Because it's an alpha, none of this is final — the project explicitly positions the channel as a place for library maintainers to catch breaking changes in CI well before they reach a Current or LTS release. The full V8 14.6-to-15.6 changelog was described in the release notes as still forthcoming.

The size of the V8 jump is itself notable. Moving from V8 14.6 to 15.6.75.13 in one step covers several V8 release cycles' worth of engine changes at once — something the old schedule would typically have spread across two separate major Node.js versions. That's a direct consequence of the new Alpha phase: because semver-major changes are explicitly allowed to accumulate during the six-month Alpha window rather than being staged across an odd and then an even release, a single annual major can absorb a larger batch of engine and dependency upgrades in one go.

What library and framework maintainers should do now

The Node.js release team's own guidance in the announcement is aimed squarely at the ecosystem, not just end users: add the Alpha channel to continuous integration pipelines early, rather than waiting until a version reaches Current or LTS to test against it. Under the new model, Alpha is the only phase where breaking engine and runtime changes are expected to land, which makes it the highest-value — and highest-risk — target for compatibility testing.

Concretely, that means:

• Native addon authors should rebuild and test against the 27.x alpha now, particularly anything that touches V8's serialization internals, given the new structured-clone format.
• Teams relying on domain, legacy OpenSSL engine configurations, or the old --experimental-wasm-* flag names should treat those as on a deprecation clock for the 27.x line.
• Anyone tuning memory limits in containers or serverless environments should explicitly set --max-old-space-size rather than relying on the new automatic half-of-physical-memory default, especially on hosts with unusual memory configurations.

What this means for developers and teams

For most production users, little changes immediately: LTS lines like Node.js 26 keep receiving security and bug fixes on their existing schedule, and the new cadence only governs how future majors are released. The practical shifts to plan for are:

• One upgrade decision per year instead of two. There's no more odd release to optionally skip — every annual major is a real, supported LTS candidate.
• Breaking changes surface earlier, in Alpha. Tooling authors, framework maintainers, and anyone running CI against "nightly" or edge builds should add the Alpha channel to their test matrix now, rather than waiting for Current.
• Fewer concurrently supported lines. With only one new major line entering support each year, teams should expect less overlap between actively maintained LTS versions than under the old odd/even system.

Teams evaluating their current Node.js footprint can compare options in our breakdown of Node.js 26 vs. Node.js 24, and bundler or tooling teams tracking ecosystem shifts may also want to see how this lines up against build-tool changes covered in Vite vs. Webpack vs. Turbopack.

The schedule isn't locked in yet

Node.js's own announcement is notably hedged: the dates and phase lengths above are the current published plan, not a guarantee. The blog post states the schedule "is not final and may be amended" and points to continued discussion at the Node.js Collaboration Summit. The project maintains the authoritative, up-to-date version of the schedule as a machine-readable schedule.json file in the nodejs/Release repository on GitHub, which is the best source to check before committing to any of the dates in this piece long-term.

What to watch next

Expect incremental alpha builds (27.0.0-alpha.1 and beyond) through early 2027 as the release team backports and tests semver-major changes, followed by beta/release-candidate builds ahead of the planned April 2027 Current release. Developers maintaining libraries, native addons, or build tooling should start validating against the 27.x alpha now, since this is the first release cycle designed specifically to surface breaking changes before they hit a supported line. Production users on Node.js 26 don't need to act yet — that LTS line continues on its existing support timeline regardless of how the 27.x schedule evolves.

Written byFelix Moreau

Felix Moreau writes Pandromeda's software coverage and how-to guides. He covers Windows, macOS and Linux updates, the apps people rely on, emulators and developer tools, and turns official documentation into clear, numbered steps that work on the current version.

More from Felix MoreauAll Software & Guides coverage