Blog: Evolving the Node.js Release Schedule#8631
Blog: Evolving the Node.js Release Schedule#8631UlisesGascon wants to merge 6 commits intonodejs:mainfrom
Conversation
- Add "About the Alpha Channel" section explaining: - Target audience (library authors, CI pipelines) - Expectations (no security patches, API may change) - Rationale (feedback loop + V8 updates) - ABI stability noted as TBD - Simplify schedule phases: Alpha → Current → LTS (29 months) - Remove Active LTS / Maintenance distinction - Add Ubuntu release cycle comparison for familiarity - Clean up v26/v27 timelines (remove Maintenance milestone)
- Add comprehensive 10-year schedule table (v27-v36) with Alpha, Release, LTS, and End of Life dates - Clarify that Alpha channel uses only nightly builds (no formal alpha releases, reducing releaser workload) - Link to nodejs.org/download/nightly for early testing - Reorder Timeline section: v26 → v27 → 10-year table
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
👋 Codeowner Review RequestThe following codeowners have been identified for the changed files: Team reviewers: @nodejs/releasers @nodejs/nodejs-website Please review the changes when you have a chance. Thank you! 🙏 |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #8631 +/- ##
==========================================
+ Coverage 75.01% 75.04% +0.03%
==========================================
Files 103 104 +1
Lines 9068 9088 +20
Branches 315 315
==========================================
+ Hits 6802 6820 +18
- Misses 2264 2266 +2
Partials 2 2 ☔ View full report in Codecov by Sentry. |
| @@ -0,0 +1,114 @@ | |||
| --- | |||
| date: '2026-04-01T00:00:00.000Z' | |||
There was a problem hiding this comment.
This is just a placeholder, no idea when makes sense to publish it.
| - **Every release becomes LTS**. No more odd/even distinction. | ||
| - **Alpha channel replaces odd-numbered releases** for early testing | ||
| - **Version numbers align with years**: `27.x` in 2027, `28.x` in 2028 | ||
| - **Maximum 3 active release lines** (down from 5) |
There was a problem hiding this comment.
down from 5
When did that last happen?
There was a problem hiding this comment.
also s/active/supported/ as "active lts" was a defined term in release phases
There was a problem hiding this comment.
It happens every year, e.g. next time will be between 2026-04-22 and 2026-04-30 there will be:
- 20.x
- 22.x
- 24.x
- 25.x
- 26.x
And there's always main as well
There was a problem hiding this comment.
@aduh95 I don't think every? Last time the overlap was in 2023 for under 2 weeks.
My point is: this change doesn't remove two supported branches, it removes at most one.
There were never two supported odd branches at the same moment.
It can't go from 5 to 3.
Current schedule gives 4 with sometimes small overlaps raising that to 5 for a few days.
And those overlaps always involve even branches, not the removed odd ones.
This new schedule gives 3 but only assuming overlaps never happen anymore:
And there's always
mainas well
And if we count main it definitely is not down to 3.
There was a problem hiding this comment.
I don't think every? Last time the overlap was in 2023 for under 2 weeks.
The only exception has been 2024 because Node.js 16 was cut early due to the OpenSSL EOL. It looks like two weeks (and on 2025, it even looks like negative time, but let me tell it was not!) but that's not telling the whole story: we have to prepare the new release line in advance and maintain it on top of the other lines ahead of its release date, so there's at least 4 weeks of overlap.
With the new schedule, we can avoid the overlap altogether because:
- cutting the alpha in October, we don't have to worry too much about making sure every deps is up-to-date etc, those can come later, meaning less preparation work
- cutting the semver in April, much of the preparation work would have happened in advance, and delays would be much lower stakes (last year 24.0.0 was delayed by the V8 update, which was a quite stressful situation for everyone involved because we ended up in a situation where the project had no current release lines ready, which can't happen with the proposed schedule).
Whether alpha releases should or should not count is debatable, one can argue that it will still be 4 release lines.
That being said, I don't mind this being re-written to focus less on the number of release lines and more on the difference it makes for releasers.
|
|
||
| ### About the Alpha Channel | ||
|
|
||
| The Alpha channel replaces odd-numbered releases. Alpha releases are signed, tagged, and tested through CITGM. This is different from [nightly builds](https://nodejs.org/download/nightly/), which remain available as automated untested builds from main. |
There was a problem hiding this comment.
Nit: imo CITGM could use a link or explanation - I expect very very few of the people reading this will know what it is.
There was a problem hiding this comment.
Perhaps just remove "through CITGM" and leave it to say "and tested"? That still gives a difference between Alpha and nightly, which says "automated untested".
But then CITGM is referred to later on, so perhaps it does need to be explained?
8 participants
Preview url: https://nodejs-org-git-fork-ulisesgascon-release-announcement-openjs.vercel.app/en/blog/announcements/evolving-the-nodejs-release-schedule
Objective
This is an initial draft of the blog post, intended to collect feedback and iterate until we have a clear plan for communicating the release schedule change.
Context
We have been discussing this topic for a while in nodejs/Release#1113, nodejs/Release#953 and at the Collaboration Summit Chesapeake 2025.
The goal of this post is to communicate the change clearly to users as part of the messaging around Node 26.x, since the new plan will take effect starting with Node 27.x. We decided to write this blog post during our last Release WG meeting.