Release
1.0.0
| Freigeben | Status | Codename | Erstveröffentlichung | Aktive LTS -Start | Wartungsstart | Lebensende |
|---|---|---|---|---|---|---|
| 18.x | Wartung | Wasserstoff | 2022-04-19 | 2022-10-25 | 2023-10-18 | 2025-04-30 |
| 20.x | Wartung | Eisen | 2023-04-18 | 2023-10-24 | 2024-10-22 | 2026-04-30 |
| 22.x | Lts | Jod | 2024-04-24 | 2024-10-29 | 2025-10-21 | 2027-04-30 |
| 23.x | Aktuell | 2024-10-15 | - - | 2025-04-01 | 2025-06-01 | |
| 24.x | Ausstehend | 2025-04-22 | 2025-10-28 | 2026-10-20 | 2028-04-30 |
Daten können sich ändern.
Der Veröffentlichungsplan ist auch als JSON -Datei verfügbar.
Es gibt drei Phasen, in denen ein Node.js -Veröffentlichung in "aktuell", "aktive Langzeitunterstützung (LTS)" und "Wartung" vorliegen kann. Leitungen mit ungeraden Zahlen werden nicht zu LTS gefördert - sie werden nicht die "aktiven LTs" oder "Wartung" -Anphasen durchlaufen.
nodejs/node landen.Änderungen, die für kritische Sicherheits- und Fehlerbehebungen erforderlich sind, können zu Semver-Major -Änderungen führen, die in einem Release-Strom landen, solche Situationen werden selten sein und als Semver-Minor landen. Diese Änderungen sollten jedoch eine Rückkehroption enthalten.
Der Begriff "unterstützte Release-Linien" wird verwendet, um auf alle Release-Zeilen zu verweisen, die nicht am Ende des Lebens sind.
| Freigeben | Status | Codename | Erstveröffentlichung | Aktive LTS -Start | Wartungs -LTS -Start | Lebensende |
|---|---|---|---|---|---|---|
| v0.10.x | Lebensende | - - | 2013-03-11 | - - | 2015-10-01 | 2016-10-31 |
| v0.12.x | Lebensende | - - | 2015-02-06 | - - | 2016-04-01 | 2016-12-31 |
| 4.x | Lebensende | Argon | 2015-09-08 | 2015-10-01 | 2017-04-01 | 2018-04-30 |
| 5.x | Lebensende | 2015-10-29 | - - | 2016-06-30 | ||
| 6.x | Lebensende | Bor | 2016-04-26 | 2016-10-18 | 2018-04-30 | 2019-04-30 |
| 7.x | Lebensende | 2016-10-25 | - - | 2017-06-30 | ||
| 8.x | Lebensende | Kohlenstoff | 2017-05-30 | 2017-10-31 | 2019-01-01 | 2019-12-31 |
| 9.x | Lebensende | 2017-10-01 | - - | 2018-06-30 | ||
| 10.x | Lebensende | Dubnium | 2018-04-24 | 2018-10-30 | 2020-05-19 | 2021-04-30 |
| 11.x | Lebensende | 2018-10-23 | - - | 2019-06-01 | ||
| 12.x | Lebensende | Erbium | 2019-04-23 | 2019-10-21 | 2020-11-30 | 2022-04-30 |
| 13.x | Lebensende | 2019-10-22 | - - | 2020-06-01 | ||
| 14.x | Lebensende | Fermium | 2020-04-21 | 2020-10-27 | 2021-10-19 | 2023-04-30 |
| 15.x | Lebensende | 2020-10-20 | - - | 2021-06-01 | ||
| 16.x | Lebensende | Gallium | 2021-04-20 | 2021-10-26 | 2022-10-18 | 2023-09-11 |
| 17.x | Lebensende | 2021-10-19 | - - | 2022-06-01 | ||
| 19.x | Lebensende | 2022-10-18 | - - | 2023-06-01 | ||
| 21.x | Lebensende | 2023-10-17 | - - | 2024-04-01 | 2024-06-01 |
Der Zweck der Release -Arbeitsgruppe ist:
Seine Verantwortlichkeiten sind:
Die Release -Arbeitsgruppe ist in Teams aufgebaut und die Mitgliedschaft in der Arbeitsgruppe führt nicht automatisch zu einer Mitgliedschaft in diesen Teams. Diese Teams sind:
Das releasers -Team wird mit den Geheimnissen und dem CI -Zugang beauftragt, um Building- und Sign -Releases zu erstellen. Ergänzungen zum Releasers -Team müssen vom TSC nach dem in Governance.MD beschriebenen Prozess genehmigt werden.
Das Release -Team verwaltet den Prozess/Inhalt von LTS -Veröffentlichungen und das erforderliche Rückbau für diese Releases. Ergänzungen zum Release -Team müssen vom Rest des Release -Teams abgemeldet werden.
Das Canary in the Gold Mine (CITGM) -Team behält CITGM als eine der wichtigsten Veröffentlichungen für Veröffentlichungen bei. Dieses Team unterhält das CITGM -Repository und arbeitet daran, CITGM -Builds regelmäßig laufen zu lassen. Dies beinhaltet auch die Aufrechterhaltung der CI -Jobs in Zusammenarbeit mit der Build -Arbeitsgruppe.
Neue Semver-Major- Releases von Node.js sind alle sechs Monate von main . Im April werden im April neue Versionen für gerade zahlreiche Versionen veröffentlicht und im Oktober ungerade Versionen.
In Abstimmung mit einer neuen Major-Veröffentlichung mit ungeraden Zahlen wird die vorherige Major-Version zur langfristigen Unterstützung zu einer langfristigen Unterstützung übergehen. Der Übergang zur langfristigen Unterstützung erfolgt in einer Semver-Minor -Veröffentlichung und sollte nach der Veröffentlichung der neuen Hauptversion erfolgen.
Jede gleichmäßige (LTS) Major -Version wird ab dem Datum, an dem er in die LTS -Berichterstattung eingeht, aktiv für 12 Monate verwaltet. Nach diesen 12 Monaten aktiven Unterstützung wird die Hauptversion 18 Monate in den "Wartungsmodus" übergehen. Vor dem Knoten.js 12 betrug der aktive Zeitraum 18 Monate und der Wartungszeitraum 12 Monate. Siehe Veröffentlichungsphasen für Details, von denen Änderungen in jeder Freisetzungsphase erwartet werden.
Das genaue Datum, an dem eine Veröffentlichung auf LTS verlegt wird, zwischen LTS -Modi oder veraltet wird, wird spätestens am ersten Tag des Monats ausgewählt, in dem es sich ändern soll. Wenn das Release -Team das Veröffentlichungsdatum ändern will, erfolgt dies mit einer Kündigungsmarkierung von mindestens 14 Tagen.
Alle LTS -Veröffentlichungen werden einen Codenamen zugewiesen. Eine Liste der erwarteten kommenden Codenamen finden Sie in Codenamen.md.
Jede LTS -Major -Version verfügt über zwei Zweige im Github -Repository: einen Release -Zweig und einen Staging -Zweig. Der Release -Zweig wird zum Schneiden neuer Veröffentlichungen verwendet. Nur Mitglieder des @nodeJS/Releasers -Teams sollten Commits in Release -Filialen landen. Der Staging-Zweig wird verwendet, um Kirsch- oder Backport-Commits von Main zu landen, die in einer zukünftigen Veröffentlichung aufgenommen werden müssen. Nur Mitglieder von @nodeJS/Backporters sollten sich auf die Staging -Zweige landen.
Zum Beispiel gibt es für Node.js v4 einen v4.x Zweig und einen v4.x-staging Zweig. Wenn sich Commits in Main landet und für eine zukünftige Node.js V4-Veröffentlichung kirschen müssen, müssen diese in den Zweig v4.x-staging gelandet werden. Wenn Commits für einen zukünftigen Node.js V4-Veröffentlichung zurückgeschrieben werden, müssen diese in Form von Pull-Anfragen gegen den v4.x-staging Zweig erfolgen. Commits werden nur in der v4.x -Filiale gelandet, wenn eine neue Version v4.x erstellt wird.
Im Allgemeinen wird erwartet, dass Änderungen mindestens 2 Wochen in einer aktuellen Veröffentlichung leben, bevor sie zurückgeschrieben werden. Es ist möglich, sich vor Ermessen der Release -Arbeitsgruppe zu verpflichten, früher zu landen.
Die Mitglieder der Arbeitsgruppe sind die Vereinigung der Releasers, Backporters und CITGM -Teammitglieder, die unten aufgeführt sind.
