Evolving the Node.js Release Schedule

Starting with 27.x, Node.js will move from two major releases per year to one. This post explains what's changing, why, and what it means for users. For the full discussion and background, see nodejs/Release#1113.

TL;DR: If you already upgrade between LTS versions, little changes beyond version numbering. LTS support windows remain similar, and the upgrade path stays the same.

Why This Change

The current release schedule is 10 years old. It was created during the io.js merger to balance the needs of a growing ecosystem. As one contributor put it at the time, it was "a guess of what enterprises would need."

We now have a decade of data showing how people actually use Node.js:

• Odd-numbered releases see minimal adoption. Most users wait for Long-Term Support.
• The odd/even distinction confuses newcomers.
• Many organizations skip odd releases entirely, upgrading only between LTS versions.

We also recognize that enterprises need predictability. The new schedule is designed to be well-defined, so teams can plan upgrades and allocate resources accordingly.

Volunteer Sustainability

Node.js is maintained primarily by volunteers. While some contributors receive sponsorship, most of the work (reviewing Pull Requests, handling security issues, cutting releases, backporting fixes) is done by people in their spare time.

Managing security releases across four or five active release lines has become difficult to sustain. Each additional line increases backporting complexity. By reducing the number of concurrent release lines, we can focus on better supporting the releases people actually use.

What's Changing

As of October 2026:

• One major release per year (April), with LTS promotion in October
• Every release becomes LTS. No more odd/even distinction - Node.js 27 will be LTS.
• Alpha channel replaces odd-numbered releases for early testing
• Version numbers align with the year of the first Interim release and transition to LTS: 27.0.0 in 2027, 28.0.0 in 2028
• Reduced Releasers' burden

New Schedule

Total support: 35 months from release to End of Life (EOL).

We took some inspiration from Ubuntu's release cycle: predictable April/October anchors, with Interim releases for testing and LTS releases for production.

About the Alpha Channel

The Alpha channel replaces odd-numbered releases. Alpha releases are signed, tagged, and tested through CITGM. CITGM (Canary in the Goldmine) is a tool we maintain that runs the test suite of major open-source packages on the upcoming version of Node.js, which can let us detect ecosystem breakage and notify the package authors ahead of the release.

This is different from Nightly builds, which remain available as automated untested builds from main – Alpha releases may not contain all changes from main, a change may be not included in an Alpha release if:

• during Pull Request review, reviewers add a label requesting the change to not be backported (e.g. if an API is getting runtime deprecated in an Alpha release, the change actually removing that API should not land until the next release line).
• during the Alpha release preparation, the releaser ultimately decides which commits actually make the release (e.g. if a dependency update contains a major bug).

Who it's for: Library authors and CI pipelines testing compatibility with upcoming breaking changes. Not intended for production use.

What to expect:

• Semver-major changes may land during this phase
• Releases are signed and tagged (unlike nightly)
• API may change between releases
• The release cadence is flexible; the Release Team will determine the timing and frequency of Alpha releases based on the volume of changes and project needs

Why: Provides early feedback on breaking changes with quality gates that Nightly builds lack. Also allows landing V8 updates earlier in the cycle.

The rules for shipping semver-major commits in Alpha versions will be defined by the Release Team and documented in the Release repository.

What's NOT Changing

• Long-Term Support duration remains similar (29 months)
• Migration windows preserved. Overlap between LTS versions remains.
• Quality standards unchanged. Same testing, same CITGM, same security process.
• Predictable schedule. April releases, October LTS promotion.
• V8 adoption cycle. Node.js latest releases will still include a version of V8 that's at most about 6 months old.

Timeline

Node.js 26 Schedule (existing model)

Node.js 26 follows the existing schedule. This is the last release line under the current model.

Node.js 27 Schedule (new model)

Node.js 27 is the first release line under the new schedule.

The Next 10 Years

This schedule is not final and may be amended. Refer to the schedule.json for an up-to-date record of the support claims from the project.

Thank You

This change is the result of discussions across GitHub issues, Release Working Group meetings, and the Collaboration Summit Chesapeake 2025. We will continue discussing this topic at the upcoming Collaboration Summit in London. We thank everyone who contributed feedback.

For questions or comments, see nodejs/Release#1113.