Node.js cambia su calendario de lanzamientos en 2026

En pocas palabras: A partir de octubre de 2026, Node.js pasa de dos versiones mayores al año a una sola (en abril), terminando el esquema par/impar desde 2015. Según el Release Working Group, el motivo real es el agotamiento del equipo de mantenimiento, que debía parchear seguridad en cuatro o cinco ramas activas simultáneas.

Node.js pasa de dos lanzamientos mayores al año a uno solo a partir de octubre de 2026, según el anuncio oficial del Release Working Group. Node.js 27 arranca su fase Alpha este mes, llega como 27.0.0 en abril de 2027 y entra en LTS en octubre de 2027. Se termina el esquema par/impar que existía desde 2015. El calendario de lanzamientos Node.js es el cronograma oficial que define cuándo sale cada versión mayor del runtime, cuánto dura su fase de soporte estándar (Current) y cuándo pasa a Long-Term Support (LTS). Lo administra el Release Working Group del proyecto, bajo la OpenJS Foundation, y hasta ahora alternaba una versión par con soporte extendido y una impar de vida corta cada seis meses.

¿Qué es lo que cambia exactamente en el esquema de versiones de Node.js?

Node.js elimina la distinción entre versiones pares (con LTS) e impares (de vida corta) y adopta un único release mayor por año, cada abril, con promoción a LTS en octubre. Así lo confirma el posteo oficial del Release Working Group: “si ya solo actualizás a versiones LTS, poco cambia más allá de la numeración”.

El esquema anterior tenía una década de antigüedad. Nació durante la fusión con io.js en 2015 como “una estimación educada de lo que las empresas iban a necesitar”, según reconoce el propio working group. Diez años de datos de uso real mostraron que las versiones impares apenas se adoptaban: la mayoría de los equipos esperaba directamente la LTS.

Ese patrón generaba un problema concreto. Cada versión impar vivía unos seis meses y, aunque casi nadie la corría en producción, el equipo de releases igual tenía que backportear parches de seguridad durante todo ese tiempo. Multiplicado por varias líneas LTS superpuestas, ahí aparecían las “cuatro o cinco líneas activas” que cita la fuente como la carga real.

¿Cómo queda el cronograma de Node.js 26 y Node.js 27?

Node.js 26 sigue el modelo viejo porque ya había salido antes del cambio: entra en LTS este octubre y llega a fin de vida (EOL) en abril de 2029. Node.js 27 es la primera versión bajo las reglas nuevas, con fases más largas y mejor definidas.

El cronograma de Node.js 27, según el blog oficial de Node.js, queda así: Alpha arranca en octubre de 2026, 27.0.0 sale en abril de 2027, entra en LTS en octubre de 2027 y llega a EOL en abril de 2030. Son 36 meses de vida total, desde el primer Current hasta el fin de soporte.

Fase	Modelo viejo (Node 26 y anteriores)	Modelo nuevo (Node 27 en adelante)
Lanzamientos mayores por año	Dos (abril y octubre)	Uno (abril)
Versiones impares “solo Current”	Sí, unos 6 meses de vida	Eliminadas
Fase Alpha	No formalizada	6 meses (octubre a marzo)
Promoción a LTS	Cada versión par, en octubre	Todas las versiones, en octubre
Ventana de soporte LTS	30 meses	30 meses (sin cambios)

Lo que salta de la tabla, y que conviene remarcar porque casi ninguna cobertura lo dice así de directo: el cambio grande no está en el soporte LTS, que sigue exactamente igual. Está en que desaparece esa ventana “Current only” que existía nada más para dar una preview temprana. En la práctica, Node.js no te da más estabilidad de la que ya tenías si esperabas LTS; simplemente le saca una rama al equipo de mantenimiento. Esto se conecta con lo que analizamos en implementar circuit breakers y timeouts en Node.js.

¿Por qué Node.js tomó esta decisión? La carga real sobre los mantenedores

Node.js está mantenido principalmente por gente voluntaria, y manejar seguridad en cuatro o cinco líneas de release activas al mismo tiempo se volvió insostenible. Eso lo dice textual el anuncio oficial: “gestionar releases de seguridad en cuatro o cinco líneas activas se volvió difícil de sostener”.

Acá está el detalle que casi nadie remarca: la ventana de soporte LTS no cambia. Sigue siendo de 30 meses. Lo que se recorta es la rama impar que vivía seis meses por año consumiendo horas de backporting sin que casi nadie la corriera en producción. Es el mismo problema de fondo detrás de las crisis de financiamiento de mantenedores en el open source en general: lo escaso no es la calidad del código, es el tiempo humano disponible.

¿Y esto resuelve algo para el usuario final? Poco, en rigor. Según el propio working group, el número de líneas LTS superpuestas en un momento dado sigue siendo el mismo, dos o tres, gobernado por la misma matemática de siempre: 30 meses de ventana y una promoción al año. Dicho sin eufemismos: le sacaron una rama al jardín, no le agregaron riego a las que quedaron.

Ejemplo hipotético (ilustrativo, no un caso real): pensemos en un equipo de plataforma que hoy corre Node.js 26 en producción y usaba la versión impar (la 27 bajo el esquema viejo) en un entorno de staging para anticipar breaking changes antes de que llegaran a LTS. Con el calendario nuevo, ese mismo equipo no tiene una “27 Current” de prueba a los seis meses: tiene una fase Alpha de 27 que arranca este mes y no se estabiliza hasta abril de 2027. Si ese equipo quiere seguir anticipando rupturas con la misma antelación que antes, el movimiento lógico no es esperar a Current, sino meter los builds Alpha en su pipeline de CI ya mismo, tal como sugiere el propio working group para mantenedores de librerías. La diferencia práctica es que antes alcanzaba con “correr la impar en un servidor aparte”, y ahora hace falta integrar Alpha al proceso de testing automatizado: es un cambio de hábito, no solo de calendario.

¿Qué críticas generó el cambio dentro de la comunidad?

La propuesta generó tensión real en la discusión pública del repositorio nodejs/Release, entre quienes valoran soporte extendido y quienes quieren acceso rápido a features nuevas. Así lo reportó InfoQ en su cobertura del debate.

James Snell, el contribuidor que diseñó originalmente el esquema actual hace una década, reconoció que estaba vencido: “cuando propuse el plan actual hace una década, estaba basado enteramente en ciclos de adopción corporativa que eran relevantes en ese momento y en realidad no lo revisamos desde entonces”, dijo Snell según InfoQ.

No todos estuvieron de acuerdo con el resultado. Kevin Lentin, describiendo la perspectiva desde una corporación grande, advirtió: “si solo recibimos LTS nueva cada 2 años, me voy a volver loco esperando features. Incluso 1 año sin backporting va a ser bastante doloroso”, citado también por InfoQ. La propuesta original es de Rafael Gonzaga, miembro del Technical Steering Committee de Node.js, abierta en julio de 2025 según el mismo medio. Más contexto en armar un pipeline CI/CD para Node.js.

El punto de fricción es simple, y es el que más me convence de que acá hay un trade-off real y no solo una mejora gratis: antes, un equipo que corría Current en un entorno no crítico tenía una versión mayor nueva para probar cada seis meses. Ahora, esperan un año entero, Alpha incluido. El working group resolvió su problema de capacidad; no resolvió, y probablemente empeoró un poco, la experiencia de quien quería ese preview de bajo riesgo cada semestre.

¿A quién afecta este cambio y quién puede ignorarlo?

El cambio afecta de lleno a equipos de plataforma e infraestructura que planifican ciclos de actualización en un calendario fijo, y a mantenedores de librerías que deciden contra qué versiones mayores siguen testeando. Para el desarrollador promedio que solo actualiza a LTS, el impacto es mínimo.

Para decidir rápido si esto te toca, el criterio no es “¿uso Node.js?” sino “¿de qué rama depende mi calendario de trabajo?”:

• Actuá ya si mantenés una librería o framework que trackea el Current de Node.js para testear compatibilidad temprana: tu calendario de testing pasó de seis meses a doce, y conviene sumar Alpha a CI antes de quedarte esperando feedback que antes llegaba al semestre.
• Actuá ya si tu política interna de actualización menciona explícitamente “versiones pares” o “solo LTS” por regla: esa regla ya no mapea limpio contra la numeración después de Node.js 27, porque ahora todas las versiones son LTS por definición.
• Actuá ya si tenías el hábito de probar la versión impar en staging como anticipo de breaking changes: ese hábito deja de existir tal cual lo conocías, y el reemplazo funcional es la fase Alpha, no la próxima Current.
• Podés ignorarlo si solo instalás la versión LTS vigente y nada más. El working group lo dice directo: poco cambia más allá del número que tipeás.
• Podés ignorarlo si gestionás dependencias con un gestor de paquetes tipo npm, pnpm o Yarn: esa elección no se toca con este cambio, que es a nivel runtime.

¿Qué deben hacer los equipos que corren Node.js en hosting o infraestructura propia?

Para la mayoría de los equipos, lo sensato es no cambiar nada: seguir trackeando LTS y anotar que el próximo punto de decisión real es la promoción a LTS de Node.js 27 en octubre de 2027, no nada de lo que pasa este mes.

El tema es que “no hacer nada” suena fácil hasta que tenés que coordinarlo en infraestructura real. Subís el entorno, probás en local, funciona bárbaro, lo llevás a producción y después te acordás de que alguien tiene que mantener ese runtime parchado contra vulnerabilidades por los próximos 30 meses, sin que eso dependa de la memoria de un solo ingeniero. Complementá con elegir entre cron y systemd para tus procesos.

Si tu equipo usa hosting gestionado, parte de ese trabajo de mantenimiento puede recaer en el proveedor en lugar de en tu equipo. Donweb, por ejemplo, ofrece planes de hosting y dominios para este tipo de infraestructura.

Para equipos de plataforma que sí dependen de Current, la jugada concreta es ajustar el calendario interno de testing ahora, antes de que la brecha más larga entre versiones mayores agarre al roadmap desprevenido.

Errores comunes al interpretar este cambio

• Pensar que “todo release es LTS” significa más soporte: la ventana sigue siendo de 30 meses, lo que cambia es la etiqueta, no la duración.
• Asumir que el ritmo de parches de seguridad se acelera: el objetivo del cambio es reducir branches activos, no agregar recursos nuevos al equipo de releases.
• Seguir reglas internas que mencionan “versión par” como sinónimo de LTS: esa convención deja de aplicar después de Node.js 27, y una política escrita así queda obsoleta.
• No actualizar el pipeline de CI de una librería para incluir los builds Alpha: el propio working group advierte que si solo testeás contra LTS, vas a reportar bugs tarde, cuando ya afectaron a usuarios.
• Confundir Alpha con nightly builds: Alpha está firmado, etiquetado y pasa por CITGM; nightly es un build automático sin testear. No son intercambiables como señal de estabilidad.

Preguntas Frecuentes

¿Qué cambia en el nuevo calendario de lanzamientos de Node.js?

Node.js pasa de dos versiones mayores al año a una sola, eliminando el esquema par/impar vigente desde 2015. Cada versión mayor nueva se promueve a LTS, con una fase Alpha formal de seis meses previa al lanzamiento Current.

¿Cuándo entra Node.js 26 en soporte LTS?

Node.js 26 entra en LTS en octubre de 2026, bajo las reglas del modelo anterior, y llega a fin de vida en abril de 2029. Es la última versión lanzada bajo el esquema viejo de dos releases al año.

¿Por qué Node.js pasa de dos lanzamientos mayores a uno por año?

Porque mantener parches de seguridad en cuatro o cinco líneas de release activas se volvió insostenible para un equipo mayormente voluntario, según el Release Working Group. Las versiones impares casi no se usaban en producción pero igual consumían horas de mantenimiento. Te puede servir nuestra cobertura de alternativas como Bun en entornos de producción.

¿Qué pasa con las versiones impares de Node.js (Current-only)?

Desaparecen por completo a partir de Node.js 27. En su lugar, cada versión mayor tiene una fase Alpha de seis meses (octubre a marzo) que cumple un rol similar de testing temprano, pero con builds firmados y probados vía CITGM, a diferencia de los builds nightly sin testear.

¿Cómo afecta este cambio a los equipos que usan Node.js en producción?

Si tu equipo ya solo instala versiones LTS, el impacto es mínimo más allá de la numeración. Si trackeás Current para acceso temprano a features, ahora esperás doce meses entre versiones mayores en vez de seis, lo que obliga a replanificar el calendario de testing.

Conclusión

El calendario de lanzamientos Node.js se simplifica en octubre de 2026: una versión mayor al año, toda LTS, con una fase Alpha formal de seis meses. Para el equipo que ya vive de LTS, es básicamente un cambio de numeración. Para mantenedores de librerías y equipos de plataforma que dependían de Current cada seis meses, el costo es real: el doble de espera para acceder a la próxima versión mayor.

Lo concreto para hacer ahora: si tu política de upgrade menciona “par/impar” por regla, reescribila. Si mantenés una librería, sumá los builds Alpha a tu CI antes de que salga 27.0.0 en abril de 2027. Y si tu infraestructura corre en hosting gestionado, confirmá con tu proveedor que el ciclo LTS se sigue respetando sin intervención manual de tu parte, que es, en definitiva, el único punto de este cambio que te debería importar si no sos vos quien mantiene el runtime.

Fuentes

• Evolving the Node.js Release Schedule – anuncio oficial del Node.js Release Working Group
• Node.js Moves to One Major Release Per Year – cobertura de InfoQ
• Node.js’s New Release Schedule Reveals a Maintainer Crisis – análisis en Dev.to