You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: apps/site/pages/en/blog/announcements/evolving-the-nodejs-release-schedule.md
+60-25Lines changed: 60 additions & 25 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,95 +6,124 @@ layout: blog-post
6
6
author: The Node.js Release Team
7
7
---
8
8
9
-
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.
9
+
Starting with 27.x, Node.js will move from two major releases per year to one.
10
+
This post explains what's changing, why, and what it means for users.
10
11
11
12
## Why This Change
12
13
13
-
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."
14
+
The current release schedule is 10 years old. It was created during the io.js
15
+
merger to balance the needs of a growing ecosystem. As one contributor put it at
16
+
the time, it was "a guess of what enterprises would need."
14
17
15
18
We now have a decade of data showing how people actually use Node.js:
16
19
17
-
- Odd-numbered releases see minimal adoption. Users wait for LTS.
20
+
- Odd-numbered releases see minimal adoption. Most users wait for Long-Term Support.
18
21
- The odd/even distinction confuses newcomers.
19
22
- Many organizations skip odd releases entirely, upgrading only between LTS versions.
20
23
21
24
### Volunteer Sustainability
22
25
23
-
Node.js is maintained primarily by volunteers. While some contributors receive sponsorship, most of the work (reviewing PRs, handling security issues, cutting releases, backporting fixes) is done by people in their spare time.
26
+
Node.js is maintained primarily by volunteers. While some contributors receive sponsorship, most
27
+
of the work (reviewing Pull Requests, handling security issues, cutting
28
+
releases, backporting fixes) is done by people in their spare time.
24
29
25
-
Managing security releases across four or five active release lines has become difficult to sustain. Each additional line increases backporting complexity. By reducing concurrent release lines, we can focus on better supporting the releases people actually use.
30
+
Managing security releases across four or five active release lines has become
31
+
difficult to sustain. Each additional line increases backporting complexity. By
32
+
reducing the number of concurrent release lines, we can focus on better
33
+
supporting the releases people actually use.
26
34
27
35
## What's Changing
28
36
29
-
Starting with `27.x` in 2027:
37
+
As of October 2026:
30
38
31
39
-**One major release per year** (April), with LTS promotion in October
32
40
-**Every release becomes LTS**. No more odd/even distinction.
33
-
-**Alpha channel replaces odd-numbered releases** for early testing
34
-
-**Version numbers align with years**: `27.x` in 2027, `28.x` in 2028
35
-
-**Maximum 3 active release lines** (down from 5)
41
+
-**Alpha channel replaces odd-numbered releases** for early testing (for librairies)
42
+
-**Version numbers align with years**: 27.0.0 in 2027, 28.0.0 in 2028
| Alpha | 5 months | Oct to Mar. Early testing, semver-major allowed |
42
-
|Current| 6 months | Apr to Oct. Stabilization |
50
+
|Interim| 6 months | Apr to Oct. Stabilization |
43
51
| LTS | 29 months | Long-term support with security fixes |
52
+
| EOL | Infinity | The project no longer provides any support |
44
53
45
54
Total support: 35 months from release to End of Life.
46
55
47
-
This model follows a pattern similar to Ubuntu's release cycle: predictable April/October anchors, with interim releases for testing and LTS releases for production.
56
+
We took some inspiration from Ubuntu's release cycle: predictable
57
+
April/October anchors, with Interim releases for testing and LTS releases for
58
+
production.
48
59
49
60
### About the Alpha Channel
50
61
51
-
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.
62
+
The Alpha channel replaces odd-numbered releases. Alpha releases are signed,
63
+
tagged, and tested through CITGM. CITGM (Canary in the Goldmine) is a tool we
64
+
maintain that runs the test suite of major open-source packages on the upcoming
65
+
version of Node.js, which can let us detect ecosystem breakage and notify the
66
+
package authors ahead of the release.
52
67
53
-
**Who it's for:** Library authors and CI pipelines testing compatibility with upcoming breaking changes. Not intended for production use.
68
+
This is different from [Nightly builds](https://nodejs.org/download/nightly/), which remain
69
+
available as automated untested builds from `main` – Alpha release may not contain all changes from
70
+
`main`, a change may be not included in an Alpha release if:
71
+
72
+
- during Pull Request review, reviewers add a label requesting the change to not be backported
73
+
(e.g. if an API is getting runtime deprecated in an Alpha release, the change actually removing
74
+
that API should not land until the next release line).
75
+
- during the Alpha release preparation, the releaser ultimately which commits actually makes the
76
+
release (e.g. if a dependency update contains a major bug).
77
+
78
+
**Who it's for:** Library authors and CI pipelines testing compatibility with
79
+
upcoming breaking changes. Not intended for production use.
54
80
55
81
**What to expect:**
56
-
- Semver-major changes land during this phase
82
+
- Semver-major changes may land during this phase
57
83
- Releases are signed and tagged (unlike nightly)
58
84
- API may change between releases
59
85
60
-
**Why:** Provides early feedback on breaking changes with quality gates that nightly builds lack. Also allows landing V8 updates earlier in the cycle.
86
+
**Why:** Provides early feedback on breaking changes with quality gates that
87
+
Nightly builds lack. Also allows landing V8 updates earlier in the cycle.
61
88
62
89
## What's NOT Changing
63
90
64
-
-**LTS support duration** remains similar (29 months)
91
+
-**Long-Term Support duration** remains similar (29 months)
65
92
-**Migration windows preserved**. Overlap between LTS versions remains.
66
93
-**Quality standards unchanged**. Same testing, same CITGM, same security process.
67
94
-**Predictable schedule**. April releases, October LTS promotion.
95
+
-**V8 adoption cycle**. Node.js latest releases will still include a version of
| 27.x | Oct 2026 | Apr 2027 | Oct 2027 | Mar 2030 |
100
129
| 28.x | Oct 2027 | Apr 2028 | Oct 2028 | Mar 2031 |
@@ -107,8 +136,14 @@ The Alpha channel replaces odd-numbered releases. Alpha releases are signed, tag
107
136
| 35.x | Oct 2034 | Apr 2035 | Oct 2035 | Mar 2038 |
108
137
| 36.x | Oct 2035 | Apr 2036 | Oct 2036 | Mar 2039 |
109
138
139
+
This schedule is not final and may be amended. Refer to the
140
+
[`schedule.json`](https://github.com/nodejs/Release/blob/HEAD/schedule.json) for an up-to-date
141
+
record of the support claims from the project.
142
+
110
143
## Thank You
111
144
112
-
This change is the result of discussions across GitHub issues, Release Working Group meetings, and [the Collaboration Summit Chesapeake 2025](https://youtu.be/ppi87YjU9x0?si=NFF5WKIGDJE_U-_V&t=6524). We thank everyone who contributed feedback.
145
+
This change is the result of discussions across GitHub issues, Release Working Group meetings, and
0 commit comments