Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Node.js Release Working Group

NotificationsYou must be signed in to change notification settings

nodejs/Release

Repository files navigation

Release schedule

ReleaseStatusCodenameInitial ReleaseActive LTS StartMaintenance StartEnd-of-life
20.xMaintenanceIron2023-04-182023-10-242024-10-222026-04-30
22.xLTSJod2024-04-242024-10-292025-10-212027-04-30
24.xCurrent2025-05-062025-10-282026-10-202028-04-30

Dates are subject to change.

LTS Schedule

The Release schedule is available also as aJSON file.

Release Phases

There are three phases that a Node.js release can be in: 'Current', 'ActiveLong Term Support (LTS)', and 'Maintenance'. Odd-numbered release lines are notpromoted to LTS - they will not go through the 'Active LTS' or 'Maintenance'phases.

  • Current - Should incorporate most of the non-major (non-breaking)changes that land onnodejs/node main branch.
  • Active LTS - New features, bug fixes, and updates that have been audited bythe Release team and have been determined to be appropriate and stable for therelease line.
  • Maintenance - Critical bug fixes and security updates. New features may beadded at the discretion of the Release team - typically only in cases wherethe new feature supports migration to later release lines.

Changes required for critical security and bug fixes may lead tosemver-majorchanges landing within a release stream, such situations will be rare and willland assemver-minor. Although, those changes should have a revert option included.

The term 'supported release lines' will be used to refer to all release linesthat are not End-of-Life.

End-of-Life Releases

ReleaseStatusCodenameInitial ReleaseActive LTS StartMaintenance LTS StartEnd-of-life
v0.10.xEnd-of-Life-2013-03-11-2015-10-012016-10-31
v0.12.xEnd-of-Life-2015-02-06-2016-04-012016-12-31
4.xEnd-of-LifeArgon2015-09-082015-10-012017-04-012018-04-30
5.xEnd-of-Life2015-10-29-2016-06-30
6.xEnd-of-LifeBoron2016-04-262016-10-182018-04-302019-04-30
7.xEnd-of-Life2016-10-25-2017-06-30
8.xEnd-of-LifeCarbon2017-05-302017-10-312019-01-012019-12-31
9.xEnd-of-Life2017-10-01-2018-06-30
10.xEnd-of-LifeDubnium2018-04-242018-10-302020-05-192021-04-30
11.xEnd-of-Life2018-10-23-2019-06-01
12.xEnd-of-LifeErbium2019-04-232019-10-212020-11-302022-04-30
13.xEnd-of-Life2019-10-22-2020-06-01
14.xEnd-of-LifeFermium2020-04-212020-10-272021-10-192023-04-30
15.xEnd-of-Life2020-10-20-2021-06-01
16.xEnd-of-LifeGallium2021-04-202021-10-262022-10-182023-09-11
17.xEnd-of-Life2021-10-19-2022-06-01
18.xEnd-of-LifeHydrogen2022-04-192022-10-252023-10-182025-04-30
19.xEnd-of-Life2022-10-18-2023-06-01
21.xEnd-of-Life2023-10-17-2024-04-012024-06-01
23.xEnd-of-Life2024-10-15-2025-04-012025-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 LTS and Current branches including backporting changes tothese branches.
  • Define the policy for what gets backported to release streams.

The Release working group is structured into teams and membership inthe working group does not automatically result in membership in theseteams. These teams are:

  • Releasers team
  • Backporters team
  • CITGM team

Thereleasers team is entrusted with the secrets and CI access to be ablebuild and sign releases.Additions to the releasers team must be approvedby the TSC following the process outlined in GOVERNANCE.md.

The Release team manages the process/content of LTS releasesand the required backporting for these releases. Additions to the Releaseteam needs sign off from the rest of the Release team.

The Canary in the Gold Mine (CITGM) team maintains CITGM as one ofthe key sanity checks for releases. This team maintains the CITGMrepository and works to keep CITGM builds running and passing regularly.This also includes maintaining the CI jobs in collaboration with the BuildWorking Group.

Release Plan

Newsemver-major releases of Node.js are branched frommain every sixmonths. New even-numbered versions are released in April and odd-numberedversions in October.

In coordination with a newodd-numbered major release, the previouseven-numbered major version will transition to Long Term Support. Thetransition to Long Term Support will happen in asemver-minor release andshould happen after the new major version is released.

Every even (LTS) major version will be actively maintained for 12 months fromthe date it enters LTS coverage. Following those 12 months of active support,the major version will transition into "maintenance" mode for 18 months. Priorto Node.js 12, the active period was 18 months and the maintenance period 12months. SeeReleases Phases for details of which changesare 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 tochange. If the release team plans to change the release date, it will be donewith no less than 14 days notice.

All LTS releases will be assigned a codename. A list of expected upcomingcodenames is available inCODENAMES.md.

LTS Staging Branches

Every LTS major version has two branches in the GitHub repository: a releasebranch 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 frommain 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 av4.x branch and av4.x-stagingbranch. When commits land in main that must be cherry-picked for a futureNode.js v4 release, those must be landed into thev4.x-staging branch. Whencommits are backported for a future Node.js v4 release, those must come in theform of pull requests opened against thev4.x-staging branch.Commits areonly landed in thev4.x branch when a newv4.x release is being prepared.

Generally, changes are expected to live in aCurrent release for at least 2weeks before being backported. It is possible for a commit to land earlier atthe discretion of the Release working group.

The working group members are the union of the Releasers, Backportersand CITGM team members listed below.

Backporters team

Releasers team

CITGM team

Emeritus

LTS team

Releasers team

About

Node.js Release Working Group

Topics

Resources

Code of conduct

Security policy

Stars

Watchers

Forks

Sponsor this project

  •  
[8]ページ先頭
©2009-2025 Movatter.jp