Node.js Release Working Group
Release schedule
| Release | Status | Codename | Initial Release | Active LTS Start | Maintenance Start | End-of-life |
|---|
| 22.x | Maintenance LTS | Jod | 2024-04-24 | 2024-10-29 | 2025-10-21 | 2027-04-30 |
| 24.x | Maintenance LTS | Krypton | 2025-05-06 | 2025-10-28 | 2026-10-20 | 2028-04-30 |
| 26.x | Active LTS | Lithium | 2026-05-05 | 2026-10-28 | 2027-10-20 | 2029-04-30 |
| Release | Status | Codename | Alpha Start | Current Start | LTS Start | End-of-life |
|---|
| 27.x | Alpha | | 2026-10-28 | 2027-04-22 | 2027-10-20 | 2030-04-30 |
Dates are subject to change.
The Release schedule is available also as a JSON file.
Release Phases
There are four phases that a Node.js release can be in: 'Alpha', 'Current',
'Active Long Term Support (LTS)', and 'Maintenance'. Starting with Node.js 27,
every release line goes through the 'Alpha' phase before its first 'Current'
release, and every release line is promoted to LTS. Those release lines stay in
'Active LTS' for the whole 30 months of Long Term Support and do not go through
the 'Maintenance' phase. See the
Evolving the Node.js Release Schedule announcement for details.
Release lines up to and including Node.js 26 follow the previous schedule: they
do not go through the 'Alpha' phase, and odd-numbered release lines were not
promoted to LTS - they did not go through the 'Active LTS' or 'Maintenance'
phases.
- Alpha - Should incorporate most of the changes that land on
nodejs/node
main branch, including semver-major (breaking) changes. Alpha releases (for
example, 27.0.0-alpha.0.0.0) are signed, tagged, and tested through
CITGM, but their API and ABI may change between releases. They are intended
for library authors and CI pipelines, not for production use.
- Current - Should incorporate most of the non-major (non-breaking)
changes that land on
nodejs/node main branch.
- Active LTS - New features, bug fixes, and updates that have been audited by
the Release team and have been determined to be appropriate and stable for the
release line.
- Maintenance (release lines up to Node.js 26 only) - Critical bug fixes and
security updates. New features may be added at the discretion of the Release
team - typically only in cases where the new feature supports migration to
later release lines.
Changes required for critical security and bug fixes may lead to semver-major
changes landing within a Current or LTS release stream, such situations will be
rare and will land as semver-minor. Although, those changes should have a
revert option included.
The term 'supported release lines' will be used to refer to all release lines
that are not End-of-Life.
End-of-Life Releases
| Release | Status | Codename | Initial Release | Active LTS Start | Maintenance LTS Start | End-of-life |
|---|
| v0.10.x | End-of-Life | - | 2013-03-11 | - | 2015-10-01 | 2016-10-31 |
| v0.12.x | End-of-Life | - | 2015-02-06 | - | 2016-04-01 | 2016-12-31 |
| 4.x | End-of-Life | Argon | 2015-09-08 | 2015-10-01 | 2017-04-01 | 2018-04-30 |
| 5.x | End-of-Life | | 2015-10-29 | - | | 2016-06-30 |
| 6.x | End-of-Life | Boron | 2016-04-26 | 2016-10-18 | 2018-04-30 | 2019-04-30 |
| 7.x | End-of-Life | | 2016-10-25 | - | | 2017-06-30 |
| 8.x | End-of-Life | Carbon | 2017-05-30 | 2017-10-31 | 2019-01-01 | 2019-12-31 |
| 9.x | End-of-Life | | 2017-10-01 | - | | 2018-06-30 |
| 10.x | End-of-Life | Dubnium | 2018-04-24 | 2018-10-30 | 2020-05-19 | 2021-04-30 |
| 11.x | End-of-Life | | 2018-10-23 | - | | 2019-06-01 |
| 12.x | End-of-Life | Erbium | 2019-04-23 | 2019-10-21 | 2020-11-30 | 2022-04-30 |
| 13.x | End-of-Life | | 2019-10-22 | - | | 2020-06-01 |
| 14.x | End-of-Life | Fermium | 2020-04-21 | 2020-10-27 | 2021-10-19 | 2023-04-30 |
| 15.x | End-of-Life | | 2020-10-20 | - | | 2021-06-01 |
| 16.x | End-of-Life | Gallium | 2021-04-20 | 2021-10-26 | 2022-10-18 | 2023-09-11 |
| 17.x | End-of-Life | | 2021-10-19 | - | | 2022-06-01 |
| 18.x | End-of-Life | Hydrogen | 2022-04-19 | 2022-10-25 | 2023-10-18 | 2025-04-30 |
| 19.x | End-of-Life | | 2022-10-18 | - | | 2023-06-01 |
| 20.x | End-of-Life | Iron | 2023-04-18 | 2023-10-24 | 2024-10-22 | 2026-04-30 |
| 21.x | End-of-Life | | 2023-10-17 | - | 2024-04-01 | 2024-06-01 |
| 23.x | End-of-Life | | 2024-10-15 | - | 2025-04-01 | 2025-06-01 |
| 25.x | End-of-Life | | 2025-10-15 | - | 2026-04-01 | 2026-06-01 |
Mandate
The Release working group's purpose is:
- Management/execution of the release and support process for all releases.
Its responsibilities are:
- Define the release process.
- Define the content of releases.
- Generate and create releases.
- Test Releases.
- Manage the Alpha, Current, and LTS branches including backporting changes to
these branches.
- Define the policy for what gets backported to release streams.
The Release working group is structured into teams and membership in
the working group does not automatically result in membership in these
teams. These teams are:
- Releasers team
- Backporters team
- CITGM team
The releasers team is entrusted with the secrets and CI access to be able
build and sign releases. Additions to the releasers team must be approved
by the TSC following the process outlined in GOVERNANCE.md.
The Release team manages the process/content of LTS releases
and the required backporting for these releases. Additions to the Release
team needs sign off from the rest of the Release team.
The Canary in the Gold Mine (CITGM) team maintains CITGM as one of
the key sanity checks for releases. This team maintains the CITGM
repository and works to keep CITGM builds running and passing regularly.
This also includes maintaining the CI jobs in collaboration with the Build
Working Group.
Release Plan
Starting with Node.js 27, a new release line is branched from main once a
year, in October, and receives Alpha releases for six months. The first Alpha
release of a new release line happens around the same time the previous release
line transitions to Long Term Support. Each April, the release line in Alpha
gets its first semver-major release (for example, 27.0.0) and enters the
'Current' phase.
Every release line stays 'Current' for six months, then transitions to Long
Term Support in October. The transition to Long Term Support will happen in a
semver-minor release. Every release line receives 30 months of Long Term
Support, for a total of 36 months from its first Current release to
End-of-Life.
Release lines up to and including Node.js 26 follow the previous schedule: new
semver-major releases were branched from main every six months, with
even-numbered versions released in April and odd-numbered versions in October.
In coordination with a new odd-numbered major release, the previous
even-numbered major version transitioned to Long Term Support. Every even
(LTS) major version is actively maintained for 12 months from the date it
enters LTS coverage. Following those 12 months of active support, the major
version transitions into "maintenance" mode for 18 months. Prior to Node.js 12,
the active period was 18 months and the maintenance period 12 months.
See Releases Phases for details of which changes are
expected to land during each release phase.
The exact date that a release will be moved to LTS, moved between LTS modes,
or deprecated will be chosen no later than the first day of the month it is to
change. If the release team plans to change the release date, it will be done
with no less than 14 days notice.
All LTS releases will be assigned a codename. A list of expected upcoming
codenames is available in CODENAMES.md.
LTS Staging Branches
Every LTS major version has two branches in the GitHub repository: a release
branch and a staging branch. The release branch is used to cut new releases.
Only members of the @nodejs/releasers team should land commits onto release branches.
The staging branch is used to land cherry-picked or backported commits from
main that need to be included in a future release. Only members of
@nodejs/backporters should land commits onto staging branches.
For example, for Node.js v4, there is a v4.x branch and a v4.x-staging
branch. When commits land in main that must be cherry-picked for a future
Node.js v4 release, those must be landed into the v4.x-staging branch. When
commits are backported for a future Node.js v4 release, those must come in the
form of pull requests opened against the v4.x-staging branch. Commits are
only landed in the v4.x branch when a new v4.x release is being prepared.
Generally, changes are expected to live in an Alpha or Current release for
at least 2 weeks before being backported. It is possible for a commit to land
earlier at the discretion of the Release working group.
The working group members are the union of the Releasers, Backporters
and CITGM team members listed below.
Backporters team
- @aduh95 - Antoine du Hamel
- @BethGriggs - Beth Griggs
- @codebytere - Shelley Vohr
- @guybedford - Guy Bedford
- @RafaelGSS - Rafael Gonzaga
- @richardlau - Richard Lau
- @sxa - Stewart X Addison
Releasers team
- @aduh95 - Antoine du Hamel
- @juanarbol - Juan José
- @marco-ippolito - Marco Ippolito
- @RafaelGSS - Rafael Gonzaga
- @richardlau - Richard Lau
- @ruyadorno - Ruy Adorno
- @sxa - Stewart X Addison
- @UlisesGascon - Ulises Gascón
CITGM team
- https://github.com/nodejs/citgm#citgm-team
Emeritus
LTS team
- @addaleax - Anna Henningsen
- @BethGriggs - Bethany Griggs
- @bnoordhuis - Ben Noordhuis
- @danielleadams - Danielle Adams
- @ErisDS - Hannah Wolfe
- @Fishrock123 - Jeremiah Senkpiel
- @geek - Wyatt Preul
- @gibfahn - Gibson Fahnestock
- @jasnell - James M Snell
- @mhdawson - Michael Dawson
- @MylesBorins - Myles Borins
- @othiym23 - Forrest L Norvell
- @rvagg - Rod Vagg
- @sam-github - Sam Roberts
- @shigeki - Shigeki Ohtsu
- @srl295 - Steven R. Loomis
- @trevnorris - Trevor Norris
- @yunong - Yunong Xiao
Releasers team
- @bengl - Bryan English
- @BethGriggs - Bethany Griggs
- @BridgeAR - Ruben Bridgewater
- @cjihrig - Colin Ihrig
- @codebytere - Shelley Vohr
- @danielleadams - Danielle Adams
- @evanlucas - Evan Lucas
- @Fishrock123 - Jeremiah Senkpiel
- @gibfahn - Gibson Fahnestock
- @jasnell - James M Snell
- @MylesBorins - Myles Borins
- @targos - Michaël Zasso
- @rvagg - Rod Vagg
/Release