Release
1.0.0
| Libérer | Statut | Nom de code | Libération initiale | LTS actif commence | Début de l'entretien | Fin de vie |
|---|---|---|---|---|---|---|
| 18.x | Entretien | Hydrogène | 2022-04-19 | 2022-10-25 | 2023-10-18 | 2025-04-30 |
| 20.x | Entretien | Fer | 2023-04-18 | 2023-10-24 | 2024-10-22 | 2026-04-30 |
| 22.x | LTS | Farceler | 2024-04-24 | 2024-10-29 | 2025-10-21 | 2027-04-30 |
| 23.x | Actuel | 2024-10-15 | - | 2025-04-01 | 2025-06-01 | |
| 24.x | En attente | 2025-04-22 | 2025-10-28 | 2026-10-20 | 2028-04-30 |
Les dates sont susceptibles de changer.
Le calendrier de version est également disponible en tant que fichier JSON.
Il existe trois phases dans lesquelles une version Node.js peut être dans: «Current», «Assistance active à long terme (LTS)» et «maintenance». Les lignes de libération impaires ne sont pas promues en LTS - elles ne passeront pas par les phases «LTS actives» ou «maintenance».
nodejs/node .Les modifications requises pour la sécurité critique et les corrections de bogues peuvent entraîner des modifications de Semver-Major qui atterrissent dans un flux de libération, de telles situations seront rares et atterriront en tant que Semver-Minor . Cependant, ces modifications devraient avoir une option de retour incluse.
Le terme «lignes de libération pris en charge» sera utilisé pour désigner toutes les lignes de libération qui ne sont pas de fin de vie.
| Libérer | Statut | Nom de code | Libération initiale | LTS actif commence | LTS de maintenance commence | Fin de vie |
|---|---|---|---|---|---|---|
| v0.10.x | Fin de vie | - | 2013-03-11 | - | 2015-10-01 | 2016-10-31 |
| v0.12.x | Fin de vie | - | 2015-02-06 | - | 2016-04-01 | 2016-12-31 |
| 4.x | Fin de vie | Argon | 2015-09-08 | 2015-10-01 | 2017-04-01 | 2018-04-30 |
| 5.x | Fin de vie | 2015-10-29 | - | 2016-06-30 | ||
| 6.x | Fin de vie | Bore | 2016-04-26 | 2016-10-18 | 2018-04-30 | 2019-04-30 |
| 7.x | Fin de vie | 2016-10-25 | - | 2017-06-30 | ||
| 8.x | Fin de vie | Carbone | 2017-05-30 | 2017-10-31 | 2019-01-01 | 2019-12-31 |
| 9.x | Fin de vie | 2017-10-01 | - | 2018-06-30 | ||
| 10.x | Fin de vie | Dubnium | 2018-04-24 | 2018-10-30 | 2020-05-19 | 2021-04-30 |
| 11.x | Fin de vie | 2018-10-23 | - | 2019-06-01 | ||
| 12.x | Fin de vie | Erbium | 2019-04-23 | 2019-10-21 | 2020-11-30 | 2022-04-30 |
| 13.x | Fin de vie | 2019-10-22 | - | 2020-06-01 | ||
| 14.x | Fin de vie | Fermium | 2020-04-21 | 2020-10-27 | 2021-10-19 | 2023-04-30 |
| 15.x | Fin de vie | 2020-10-20 | - | 2021-06-01 | ||
| 16.x | Fin de vie | Gallium | 2021-04-20 | 2021-10-26 | 2022-10-18 | 2023-09-11 |
| 17.x | Fin de vie | 2021-10-19 | - | 2022-06-01 | ||
| 19.x | Fin de vie | 2022-10-18 | - | 2023-06-01 | ||
| 21.x | Fin de vie | 2023-10-17 | - | 2024-04-01 | 2024-06-01 |
L'objectif du groupe de travail sur la version est:
Ses responsabilités sont:
Le groupe de travail sur la publication est structuré en équipes et l'adhésion au groupe de travail n'entraîne pas automatiquement l'adhésion à ces équipes. Ces équipes sont:
L'équipe releasers se voit chargé les secrets et l'accès CI pour pouvoir construire et signer les versions. Les ajouts à l'équipe Releasers doivent être approuvés par le TSC à la suite du processus décrit dans la gouvernance.md.
L'équipe de publication gère le processus / contenu des versions LTS et le recul requis pour ces versions. Des ajouts à l'équipe de sortie doivent être déconnectés du reste de l'équipe de sortie.
L'équipe Canary in the Gold Mine (CITGM) maintient CITGM comme l'un des principaux vérifications de la santé mentale pour les versions. Cette équipe maintient le référentiel CITGM et fonctionne pour que CITGM se soit déroulée et passant régulièrement. Cela comprend également le maintien des emplois CI en collaboration avec le groupe de travail de construction.
Les nouvelles versions de Semver-Major de Node.js sont ramifiées de main tous les six mois. De nouvelles versions uniformes sont publiées en avril et des versions impairs en octobre.
En coordination avec une nouvelle version majeure impair , la version majeure pair à numéro précédente passera à un support à long terme. La transition vers le support à long terme se produira dans une version de Semver-Minor et devrait se produire après la sortie de la nouvelle version majeure.
Chaque version majeure pair (LTS) sera activement maintenue pendant 12 mois à compter de la date à laquelle il entre en couverture LTS. Après ces 12 mois de support actif, la version principale passera en mode "Maintenance" pendant 18 mois. Avant Node.js 12, la période active était de 18 mois et la période de maintenance 12 mois. Voir les phases des versions pour plus de détails sur les modifications qui devraient atterrir pendant chaque phase de libération.
La date exacte à laquelle une version sera déplacée vers LTS, déplacée entre les modes LTS ou déconticulée sera choisie au plus tard le premier jour du mois qu'il doit changer. Si l'équipe de publication prévoit de modifier la date de sortie, cela se fera avec un préavis pas moins de 14 jours.
Toutes les versions LTS se verront attribuer un nom de code. Une liste des noms de code à venir attendus est disponible dans codenames.md.
Chaque version majeure LTS a deux branches dans le référentiel GitHub: une branche de version et une branche de mise en scène. La branche de libération est utilisée pour couper de nouvelles versions. Seuls les membres de l'équipe @ Nodejs / Releasers devraient atterrir les engagements dans les succursales de libération. La branche de mise en scène est utilisée pour débarquer des engins sélectionnés en cerise ou en arrière de la main qui doivent être inclus dans un futur communiqué. Seuls les membres de @ NodeJS / Backporters devraient atterrir les engagements dans des branches de mise en scène.
Par exemple, pour Node.js V4, il y a une branche v4.x et une branche v4.x-staging Lorsque les engagements atterrissent dans la principale qui doivent être sélectionnés en cerise pour une future libération de Node.js V4, celles-ci doivent être atterri dans la branche v4.x-staging Lorsque les validations sont rétroversées pour une future version de Node.js V4, celles-ci doivent se présenter sous la forme de demandes de traction ouvertes contre la branche v4.x-staging Les validations ne sont atterries que dans la branche v4.x lorsqu'une nouvelle version v4.x est en cours de préparation.
Généralement, les changements devraient vivre dans un communiqué en cours pendant au moins 2 semaines avant d'être recouverts. Il est possible pour un engagement à atterrir plus tôt à la discrétion du groupe de travail de libération.
Les membres du groupe de travail sont le syndicat des Releasers, des Backporters et des membres de l'équipe CITGM énumérés ci-dessous.
