-
-
Notifications
You must be signed in to change notification settings - Fork 6.5k
Blog: Evolving the Node.js Release Schedule #8631
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
548adaf
62a4ff2
cc35d52
3c1aa4e
295317e
1d1c970
edf1129
8e611a8
e5c2095
fc0544b
26a711c
5309f98
66a5c46
79d6b87
7dd8066
3539972
5cf9c14
463ed6d
7503c54
13f3189
23ce3d1
01ecbeb
1f5459f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,165 @@ | ||||||
| --- | ||||||
| date: '2026-04-02T00:00:00.000Z' | ||||||
| category: announcements | ||||||
| title: Evolving the Node.js Release Schedule | ||||||
| layout: blog-post | ||||||
| author: 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](https://github.com/nodejs/Release/issues/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. | ||||||
UlisesGascon marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
|
|
||||||
| **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. | ||||||
|
|
||||||
UlisesGascon marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
| ## Why This Change | ||||||
UlisesGascon marked this conversation as resolved.
Show resolved
Hide resolved
|
||||||
|
|
||||||
| 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 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. | ||||||
| - **Version numbers align with the year of the first Current release and transition to LTS**: 27.0.0 in 2027, 28.0.0 in 2028. | ||||||
|
||||||
| - **Version numbers align with the year of the first Current release and transition to LTS**: 27.0.0 in 2027, 28.0.0 in 2028. | |
| - **Version numbers align with the calendar year of their initial Current release**: 27.0.0 in 2027, 28.0.0 in 2028. |
Copilot
AI
Feb 26, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's an inconsistency in the Alpha duration. The table at line 62 states "Alpha | 5 months | Oct to Mar", but counting from October to the following April is 6 months (October, November, December, January, February, March = 6 months). The timeline table also confirms this: Alpha begins Oct 2026, and Current release is Apr 2027, which is 6 months apart. Either the duration should be corrected to "6 months" or the date range should be adjusted to match "5 months".
| | Alpha | 5 months | Oct to Mar. Early testing, semver-major allowed | | |
| | Alpha | 6 months | Oct to Mar. Early testing, semver-major allowed | |
UlisesGascon marked this conversation as resolved.
Show resolved
Hide resolved
Copilot
AI
Feb 26, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The total support duration calculation appears to be incorrect. According to the table above, Alpha is 5 months, Current is 6 months, and LTS is 29 months, which totals 40 months, not 35 months. However, if we're calculating from the first Current release (not from Alpha start), it would be 6 + 29 = 35 months. This should be clarified to specify "35 months from Current release to End of Life" or the calculation should be corrected to reflect the actual total time including Alpha.
| Total support: 35 months from release to [End of Life (EOL)](https://nodejs.org/en/about/eol). | |
| Total support: 35 months from first Current release to [End of Life (EOL)](https://nodejs.org/en/about/eol). |
UlisesGascon marked this conversation as resolved.
Show resolved
Hide resolved
Copilot
AI
Feb 26, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The phrase "to not be backported" uses a split infinitive. While this is grammatically acceptable in modern English, "not to be backported" would be more traditional and slightly more natural. This is a minor stylistic suggestion.
| - during Pull Request review, reviewers add a label requesting the change to not be backported | |
| - during Pull Request review, reviewers add a label requesting the change not to be backported |
Copilot
AI
Feb 26, 2026
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The phrase "semver-major changes are allowed during Alpha" is mentioned twice in close proximity (lines 71 and 92). While line 71 mentions it as one characteristic and line 92 lists it in the "What to expect" section, this repetition could be condensed for better readability. Consider whether both mentions are necessary or if the information could be presented more concisely.
| - Semver-major changes may land during this phase. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Adding a third author entry with the same id "nodejs" creates ambiguity in the author lookup system. The function getAuthorWithId finds the FIRST match based on object iteration order, which means "Node.js Releasers" will now be returned when querying by id "nodejs", changing the behavior from the previous expectation of returning "Node.js Technical Steering Committee". Consider using unique IDs for each author entry (e.g., "nodejs-release", "nodejs-tsc", "nodejs-project") to avoid this ambiguity and make the lookup behavior more predictable and maintainable.