Release
1.0.0
| Liberar | Estado | Nombre en código | Lanzamiento inicial | Inicio de LTS activo | Inicio de mantenimiento | Final de la vida |
|---|---|---|---|---|---|---|
| 18.x | Mantenimiento | Hidrógeno | 2022-04-19 | 2022-10-25 | 2023-10-18 | 2025-04-30 |
| 20.X | Mantenimiento | Hierro | 2023-04-18 | 2023-10-24 | 2024-10-22 | 2026-04-30 |
| 22.x | LTS | Chaveta | 2024-04-24 | 2024-10-29 | 2025-10-21 | 2027-04-30 |
| 23.x | Actual | 2024-10-15 | - | 2025-04-01 | 2025-06-01 | |
| 24.x | Pendiente | 2025-04-22 | 2025-10-28 | 2026-10-20 | 2028-04-30 |
Las fechas están sujetas a cambios.
El cronograma de lanzamiento también está disponible como archivo JSON.
Hay tres fases en las que puede estar una liberación de nodo.js: 'actual', 'soporte activo a largo plazo (LTS)' y 'mantenimiento'. Las líneas de liberación de número impar no se promueven a LTS: no pasarán por las fases 'LTS activas' o 'Mantenimiento'.
nodejs/node .Los cambios requeridos para la seguridad crítica y las correcciones de errores pueden conducir a los cambios de Semver-Major que aterrizan dentro de un flujo de liberación, tales situaciones serán raras y aterrizarán como Semver-Minor . Aunque, esos cambios deben tener una opción de revertir incluida.
El término 'líneas de lanzamiento compatibles' se utilizará para referirse a todas las líneas de lanzamiento que no son al final de la vida.
| Liberar | Estado | Nombre en código | Lanzamiento inicial | Inicio de LTS activo | Mantenimiento LTS Inicio | Final de la vida |
|---|---|---|---|---|---|---|
| V0.10.X | Final de la vida | - | 2013-03-11 | - | 2015-10-01 | 2016-10-31 |
| v0.12.x | Final de la vida | - | 2015-02-06 | - | 2016-04-01 | 2016-12-31 |
| 4.x | Final de la vida | Argón | 2015-09-08 | 2015-10-01 | 2017-04-01 | 2018-04-30 |
| 5.x | Final de la vida | 2015-10-29 | - | 2016-06-30 | ||
| 6.x | Final de la vida | Boro | 2016-04-26 | 2016-10-18 | 2018-04-30 | 2019-04-30 |
| 7.x | Final de la vida | 2016-10-25 | - | 2017-06-30 | ||
| 8.x | Final de la vida | Carbón | 2017-05-30 | 2017-10-31 | 2019-01-01 | 2019-12-31 |
| 9.x | Final de la vida | 2017-10-01 | - | 2018-06-30 | ||
| 10.x | Final de la vida | Dubnio | 2018-04-24 | 2018-10-30 | 2020-05-19 | 2021-04-30 |
| 11.x | Final de la vida | 2018-10-23 | - | 2019-06-01 | ||
| 12.x | Final de la vida | Erbio | 2019-04-23 | 2019-10-21 | 2020-11-30 | 2022-04-30 |
| 13.x | Final de la vida | 2019-10-22 | - | 2020-06-01 | ||
| 14.x | Final de la vida | Fermio | 2020-04-21 | 2020-10-27 | 2021-10-19 | 2023-04-30 |
| 15.x | Final de la vida | 2020-10-20 | - | 2021-06-01 | ||
| 16.x | Final de la vida | Galio | 2021-04-20 | 2021-10-26 | 2022-10-18 | 2023-09-11 |
| 17.x | Final de la vida | 2021-10-19 | - | 2022-06-01 | ||
| 19.x | Final de la vida | 2022-10-18 | - | 2023-06-01 | ||
| 21.x | Final de la vida | 2023-10-17 | - | 2024-04-01 | 2024-06-01 |
El propósito del grupo de trabajo de lanzamiento es:
Sus responsabilidades son:
El grupo de trabajo de lanzamiento está estructurado en equipos y la membresía en el grupo de trabajo no resulta automáticamente en la membresía en estos equipos. Estos equipos son:
Al equipo releasers se le confía los secretos y el acceso de CI para poder ver lanzamientos de construcción y firma. Las adiciones al equipo de relajamiento deben ser aprobadas por el TSC después del proceso descrito en el gobierno.
El equipo de lanzamiento gestiona el proceso/contenido de los lanzamientos de LTS y el respaldo requerido para estos lanzamientos. Las adiciones al equipo de lanzamiento necesitan firmar del resto del equipo de lanzamiento.
El equipo Canary in the Gold Mine (CITGM) mantiene CITGM como una de las verificaciones clave de la cordura para los lanzamientos. Este equipo mantiene el repositorio de CITGM y funciona para mantener las construcciones de CITGM en funcionamiento y paso regularmente. Esto también incluye mantener los trabajos de CI en colaboración con el grupo de trabajo de compilación.
Los nuevos lanzamientos de Semver-Major de Node.js están ramificados desde main cada seis meses. Las nuevas versiones uniformes se lanzan en abril y versiones impares en octubre.
En coordinación con un nuevo lanzamiento importante de umberado , la versión principal de umberada anterior pasará al soporte a largo plazo. La transición al soporte a largo plazo ocurrirá en un lanzamiento de Semver-Minor y debería ocurrir después de que se lance la nueva versión principal.
Cada versión principal par (LTS) se mantendrá activamente durante 12 meses a partir de la fecha en que ingresa a la cobertura de LTS. Después de esos 12 meses de soporte activo, la versión principal pasará al modo "Mantenimiento" durante 18 meses. Antes de Node.js 12, el período activo fue de 18 meses y el período de mantenimiento de 12 meses. Consulte las fases de lanzamiento para obtener detalles de los que se espera que los cambios aterricen durante cada fase de liberación.
La fecha exacta de que una versión se trasladará a LTS, se trasladará entre los modos LTS o se eligirá a más tardar el primer día del mes que cambiará. Si el equipo de lanzamiento planea cambiar la fecha de lanzamiento, se realizará con no menos de 14 días de anticipación.
A todas las versiones de LTS se les asignará un nombre de código. Una lista de los próximos nombres de código esperados está disponible en Codenames.md.
Cada versión principal de LTS tiene dos ramas en el repositorio de GitHub: una rama de lanzamiento y una rama de puesta en escena. La rama de lanzamiento se usa para cortar nuevos lanzamientos. Solo los miembros del equipo @NodeJS/Releasers deben aterrizar en las ramas de liberación. La rama de puesta en escena se usa para conseguir confirmaciones recolectadas o retrocedidas de cerezas de Main que deben incluirse en un lanzamiento futuro. Solo los miembros de @nodejs/backorters deben aterrizar comprometidos en las ramas de puesta en escenario.
Por ejemplo, para Node.js V4, hay una rama v4.x y una rama v4.x-staging Cuando se compromete a la tierra en Main, que debe ser recolectada para una liberación de nodo futura. JS V4, se deben aterrizar en la rama v4.x-staging Cuando las comodidades se realizan para una futura liberación de nodo.js v4, esas deben venir en forma de solicitudes de extracción abiertas contra la rama v4.x-staging . Los compromisos solo se aterrizan en la rama v4.x cuando se está preparando una nueva versión v4.x
En general, se espera que los cambios vivan en un lanzamiento actual durante al menos 2 semanas antes de ser respaldados. Es posible un compromiso para aterrizar antes a discreción del grupo de trabajo de lanzamiento.
Los miembros del grupo de trabajo son la unión de los liberadores, backorters y miembros del equipo CITGM que se enumeran a continuación.
