Node.js Releasers
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 only upgrade to LTS versions, little changes beyond version numbering. LTS support windows remain similar, and now every release becomes LTS.
Library authors: Please integrate Alpha releases to your CI as early as possible; if you only test on LTS releases, you will not be able to report bugs before they affect your users.
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 "an educated 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 to 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 become LTS.
- Alpha channel for early testing with semver-major changes allowed.
- Alpha versioning follows semver prerelease format (e.g.,
27.0.0-alpha.1
). - Version numbers align with the calendar year of their initial Current release: 27.0.0 in 2027, 28.0.0 in 2028.
- Reduced Releasers' burden.
New Schedule
| Phase | Duration | Description |
|---|---|---|
| Alpha | 6 months | Oct to Mar. Early testing, semver-major allowed |
| Current | 6 months | Apr to Oct. Stabilization |
| LTS | 30 months | Long-term support with security fixes |
| EOL | Infinity | The project no longer provides any support |
Total support: 36 months from first Current release to End of Life (EOL).
About the Alpha Channel
The Alpha channel fills the early-testing role that odd-numbered releases once served, but with a key difference: semver-major changes are allowed during Alpha. 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 not be included in an Alpha release if:
- during Pull Request review, reviewers add a label requesting the change not to 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:
- 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 (30 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)
| Milestone | Date |
|---|---|
| 26.0.0 | April 2026 |
| Enters LTS | October 2026 |
| Maintenance | October 2027 |
| End of Life | April 2029 |
Node.js 26 follows the existing schedule. This is the last release line under the current model.
Node.js 27 Schedule (new model)
| Milestone | Date |
|---|---|
| Alpha begins | October 2026 |
| 27.0.0 | April 2027 |
| Enters LTS | October 2027 |
| End of Life | April 2030 |
Node.js 27 is the first release line under the new schedule.
The Next 10 Years
| Version | Alpha | Current | LTS | End of Life |
|---|---|---|---|---|
| 27.x | Oct 2026 | Apr 2027 | Oct 2027 | Apr 2030 |
| 28.x | Oct 2027 | Apr 2028 | Oct 2028 | Apr 2031 |
| 29.x | Oct 2028 | Apr 2029 | Oct 2029 | Apr 2032 |
| 30.x | Oct 2029 | Apr 2030 | Oct 2030 | Apr 2033 |
| 31.x | Oct 2030 | Apr 2031 | Oct 2031 | Apr 2034 |
| 32.x | Oct 2031 | Apr 2032 | Oct 2032 | Apr 2035 |
| 33.x | Oct 2032 | Apr 2033 | Oct 2033 | Apr 2036 |
| 34.x | Oct 2033 | Apr 2034 | Oct 2034 | Apr 2037 |
| 35.x | Oct 2034 | Apr 2035 | Oct 2035 | Apr 2038 |
| 36.x | Oct 2035 | Apr 2036 | Oct 2036 | Apr 2039 |
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.
Facts Only
Node.js will move from two major releases per year to one, starting with version 27.x.
The change is effective as of October 2026.
Every release will become LTS, eliminating the odd/even distinction.
The new schedule includes a 6-month Alpha phase, a 6-month Current phase, and 30 months of LTS support.
Alpha releases allow semver-major changes and are intended for early testing by library authors and CI pipelines.
Alpha releases are signed, tagged, and tested through CITGM but are not recommended for production use.
The total support duration is 36 months from the first Current release to EOL.
Node.js 26 follows the existing schedule, with 26.0.0 in April 2026, LTS in October 2026, and EOL in April 2029.
Node.js 27 will begin Alpha in October 2026, with the Current release in April 2027, LTS in October 2027, and EOL in April 2030.
The project is maintained primarily by volunteers.
The decision is based on a decade of data showing minimal adoption of non-LTS releases.
The new schedule aims to reduce the burden on releasers and improve sustainability.
Executive Summary
Full Take
The strongest version of this narrative is that Node.js is making a pragmatic, data-driven decision to streamline its release cycle. By reducing the number of major releases and eliminating the odd/even distinction, the project aims to simplify adoption for users and reduce the workload on its volunteer maintainers. The introduction of the Alpha channel provides a structured way for early testing and feedback, which could improve the stability of LTS releases. The decision is well-supported by a decade of usage data and aims to address real pain points in the ecosystem.
However, it's worth questioning whether this change could inadvertently reduce the pace of innovation. By consolidating major releases, Node.js might slow down the introduction of new features, which could affect developers who rely on cutting-edge capabilities. Additionally, while the Alpha channel is a positive step, its success depends on active participation from library authors and the broader community. If adoption of Alpha testing is low, the benefits of early feedback might not materialize.
The paradigm driving this narrative is one of sustainability and pragmatism. The unstated assumption is that the current release cycle is unsustainable for volunteers and that most users prioritize stability over rapid innovation. This echoes a broader trend in open-source projects where maintainers are increasingly focusing on sustainability and reducing burnout.
The implications for human agency and dignity are mixed. On one hand, this change could empower developers by providing a more predictable and stable release cycle. On the other hand, it might limit the agency of those who rely on frequent updates for new features. The costs are primarily borne by library authors who need to adapt to the new Alpha testing process, while the benefits accrue to the broader ecosystem in terms of stability and reduced maintenance burden.
Bridge questions to consider: How might this change affect the pace of innovation in the Node.js ecosystem? What mechanisms could be put in place to ensure that the Alpha channel receives sufficient participation from library authors? What would it take to change your mind about the effectiveness of this new release schedule?
Counterstrike scan: If this narrative were part of a coordinated influence campaign, the playbook might involve emphasizing the benefits of stability and sustainability while downplaying potential drawbacks like reduced innovation. However, the actual content does not match this pattern, as it openly acknowledges the trade-offs and provides a transparent rationale for the change.
Sentinel — Human
The article shows strong signs of human authorship, with natural language variation, specific technical details, and a clear, passionate voice.