instalar - ¿Por qué se recomienda node.js v4.4.5 sobre v6.2.0 “para la mayoría de los usuarios”?

update node js

Question

Utilicé node.js para un proyecto de desarrollo hace unos años, y esta aplicación está un poco "cerrada" por el momento: necesita estar en línea, necesita estar segura, pero no debería necesitar mucha atención. Actualmente se está ejecutando en node.js v0.10.32, pero ahora me gustaría invertir en una migración "final" a una versión de Soporte a largo plazo (LTS) para que sea más fácil de mantener en el futuro previsible.

A primera vista, la página de inicio de node.js hace que parezca que v4.4.5 es obviamente la única versión de LTS disponible:

Sin embargo, si hago clic en el enlace de programación de LTS , cuenta una historia diferente. Por lo que puedo decir, la versión 6 de node.js también está programada para ser una versión LTS, y ese soporte finalizará un año más tarde que la versión 4.

Dado que:

• v6.2.0 es una versión versionada
• Se supone que v6 recibirá mantenimiento LTS hasta 2019-04-01
• theoretically ningún cambio en v6.x debería romper la compatibilidad hacia atrás

¿Por qué me molestaría en actualizar a v4 en lugar de v6? Parece que v4 me compra un año menos de parches de seguridad, pero ¿no hay garantías de compatibilidad adicionales?

Answer 1

Con gratitud a jasnell y TheAlphaNerd que pacientemente respondieron mis preguntas mordaces en GitHub, he aquí cómo entiendo cómo se manejan las versiones de "soporte a largo plazo" de node.js:

• Todas las versiones basadas en una rama principal de número par son lo que otros proyectos podrían llamar una versión de "soporte a largo plazo". Se les promete al menos 30 meses de soporte desde el primer "corte" disponible (por ejemplo, una versión v6.0.0 empaquetada).

• Sin embargo, los mantenedores de node.js ven "LTS" como una fase de lanzamiento más que un tipo de versión. Si bien pretenden lanzamientos menores / parches realizados cuando una rama importante se encuentra en su fase de mejora activa (ver "ACTUAL" a continuación) para ser estable y compatible con versiones anteriores, en el mundo real podrían cometer errores.

Así que dividen el desarrollo en tres fases distintas :

1. ACTUAL: nuevas características (y correcciones de errores y parches de seguridad)
2. ACTIVE LTS: correcciones de errores (y parches de seguridad)
3. MANTENIMIENTO: sólo parches de seguridad.

Las versiones principales con números impares obtienen solo la primera fase antes de quedarse atrás. Las versiones principales con números pares (las que más nos preocupan aquí) pasan por las tres fases .

La fase ACTUAL comienza con el primer lanzamiento público y comienza a marcar el reloj en la ventana de soporte de 30 meses. Pueden agregar nuevas características importantes, que en teoría deberían ser compatibles con versiones anteriores, pero en la práctica pueden surgir algunos problemas (se agrega un nuevo error, se hace un cambio a un comportamiento mal definido, solucionan un error antiguo que había solucionado mal, etc.) )

Luego, en algún momento, el equipo decide mover el esfuerzo de desarrollo principal a una rama principal de número impar de corta duración (probablemente cuando necesitan romper la compatibilidad hacia atrás intencionalmente). En ese punto, la rama con número par se mueve a ACTIVE LTS y se ponen mucho más cuidadosos con los cambios que hacen: principalmente solo correcciones de errores. Entonces, si realmente desea estabilidad, este es el momento de estar "a bordo" con una versión en particular.

Finalmente, se mueve aún más a la fase de MANTENIMIENTO, donde el código se toca solo en respuesta a los errores más críticos (piense: parches de seguridad). Pero para entonces es probable que ya haya un nuevo lanzamiento en la "fase" de LTS.

Por lo tanto, la elección en la página de inicio en este momento es entre dos ramas pares, "v4.4.5 LTS" y "v6.2.0 actual". Si la rama más nueva tuviera un número impar, no sería un buen candidato para un despliegue de producción donde se desea un soporte a largo plazo.

Mis opciones reales son un poco más complejas incluso:

Simplemente podría permanecer en v0.10, que tendrá correcciones críticas hasta octubre. O subir hasta v0.12 para obtenerlos hasta el final del año. Pero ninguno de los dos me gana mucho, así que los descartaré.

Puedo implementar v4.4.5, que todavía está recibiendo correcciones de errores generales en este momento, y recibiré correcciones de seguridad durante bastante tiempo todavía. Esto debería darme la instalación más estable. Sin embargo, el ciclo de soporte ya está a mitad de camino, y cuando se agote, ya habré perdido esta oportunidad para ponerme al día con algunos de los principales cambios que ya han ocurrido en v5 y v6.

Me estoy inclinando hacia el despliegue de v6.2.0, asumiendo que todas mis dependencias lo soportan ahora mismo. Esto no solo me compra un período más largo de "ciclo de vida restante", sino que también me pone al día con los cambios de ruptura que se introdujeron entre v0.10 y ahora. (También me da acceso a cualquier función nueva útil, pero en este caso no tengo la oportunidad de aprovecharla). El riesgo que corro es que cuando actualizo a cualquier versión v6.2.1 o v6.3.0 hipotética o Más allá de eso viene, puede dar accidentalmente algunas sorpresas desagradables.

En mi caso, prefiero lidiar ahora con los principales cambios intencionales que v5 y v6 ya han introducido, y luego espero que esté todo listo (o al menos solo un dolor menor) desde ahora hasta abril de 2019.