Node.js abandona el modelo par-impar. Cómo planificar sus actualizaciones ahora.
Node.js está cambiando la forma en que publica versiones mayores, y el modelo mental que todos los equipos de backend han utilizado durante una década está desapareciendo. A partir de la versión 27, el proyecto pasa de dos versiones mayores al año a una. La regla par-impar, en la que las versiones de número impar tenían una vida corta y las de número par se convertían en soporte a largo plazo, está siendo retirada. Cada versión anual se convertirá ahora en LTS.
El nuevo ritmo es sencillo. Una versión mayor llega cada abril, con promoción a LTS el octubre siguiente. Los números de versión se alinean con el año calendario de la primera fase Current de un lanzamiento, así que 27.0.0 llega en abril de 2027, 28.0.0 en 2028, y así sucesivamente. También hay un nuevo canal Alpha de seis meses, que va de octubre a marzo, donde se permiten cambios de ruptura (semver-major) y el equipo de lanzamiento ejecuta las suites de pruebas de los paquetes más populares contra la próxima versión a través de CITGM. Node.js 26, la línea que se lanzó este mayo, es la última bajo el modelo anterior. El Alpha de Node 27 abre este octubre.
¿Qué significa esto realmente si ejecuta Node en producción? Menos de lo que el titular sugiere, y ese es precisamente el punto.
Si su equipo ya fija la versión en LTS e ignora la línea Current, casi nada cambia excepto la aritmética de versiones. Todavía actualiza aproximadamente cada dos años, y todavía obtiene alrededor de 30 meses de soporte por línea. Hemos gestionado muchos proyectos empresariales de larga duración de esta manera, el trabajo de cumplimiento normativo suizo en particular, donde «aburrido y predecible» es una característica, no una queja. Eliminar la regla par/impar elimina principalmente una pieza de folclore en la que los recién contratados siempre tropezaban.
El verdadero cambio es el canal Alpha, y está dirigido a un grupo al que la mayoría de los equipos olvida que pertenece: cualquiera que mantenga una biblioteca, un SDK o un paquete interno compartido. Durante años, las versiones de número impar eran donde los problemas de compatibilidad surgían primero, y casi nadie las probaba. Ahora hay una ventana explícita de seis meses, de octubre a marzo, para detectar un cambio de ruptura antes de que llegue al LTS del que dependen sus clientes. Desde nuestro trabajo con PHP y Docker, hemos visto la misma película en otros ecosistemas: el problema rara vez está en el propio framework, sino en alguna dependencia transitiva que nadie probó contra la beta. Un canal Alpha anual es el proyecto entregándole una fecha fija para descubrirlo.
Esta es la parte práctica. Agregue un trabajo de Node Alpha a su CI ahora, antes de octubre, aunque esté permitido que falle. Una sola entrada en la matriz que ejecute su suite de pruebas contra el último Node Alpha e informe sin bloquear la compilación. Le cuesta un trabajo extra, y convierte «nuestra aplicación falló con el nuevo Node» en un ticket que presenta en noviembre en lugar de un incendio que combate la primavera siguiente. Si publica paquetes, esto no es opcional. Es la forma de evitar ser la dependencia que rompe a todos los demás.
Una reflexión sobre el hábito de actualización que esto fomenta. Un major anual predecible es positivo, pero «predecible» puede adormecer a los equipos en el piloto automático. Lo vemos también en mobile. En nuestros proyectos nativos de iOS y Android, un lanzamiento anual del sistema operativo entrena a los equipos para esperar una transición tranquila, hasta el año en que no lo es. Trate cada major de Node como una migración real con su propia pasada de pruebas, no como un mero trámite. La ventana Alpha existe precisamente para que el lanzamiento de abril pueda ser aburrido.
Hay un ángulo de seguridad que vale la pena mencionar. Líneas de tiempo de soporte más claras significan menos equipos ejecutando accidentalmente un runtime al final de su vida útil porque perdieron la pista de qué línea era «par» y cuál era un callejón sin salida. Durante nuestros trabajos de pentesting, una versión de Node sin soporte es uno de los hallazgos más comunes, generalmente un servicio antiguo que nadie gestiona ya. Que todas las líneas se conviertan en LTS, con un ciclo limpio de 30 meses, convierte «¿estamos en un runtime con soporte?» en una pregunta de sí o no en lugar de un diagrama de flujo. Registre esa fecha de EOL en su rastreador de dependencias hoy mismo.
En lo que sigo pensando: esto es Node admitiendo que la mayoría de los equipos nunca utilizó el ritmo de lanzamiento de la manera en que fue diseñado. Un major al año, todos con soporte, problemas de compatibilidad detectados con antelación a través de Alpha. Es menos ingenioso y más honesto, y después de años de explicar par/impar a los clientes, me quedo con lo honesto.
Si mantener una flota de servicios Node en versiones de runtime con soporte y bien probadas le resulta familiar, hablemos.