Pourquoi la version 4.4.5 de node.js est-elle recommandée par rapport à la version 6.2.0 "pour la plupart des utilisateurs" ?

Question

J'ai utilisé node.js pour un projet de développement il y a quelques années, et cette application est en quelque sorte "mise en veilleuse" pour le moment - elle doit rester en ligne, elle doit rester sécurisée, mais elle ne devrait pas nécessiter beaucoup d'attention. Elle fonctionne actuellement sur node.js v0.10.32, mais je voudrais maintenant investir dans une migration "finale" vers une version Long Term Support (LTS) afin qu'elle soit plus facile à maintenir dans un avenir proche.

À première vue, la page d'accueil de node.js donne l'impression que la version 4.4.5 est la seule version LTS disponible :

Cependant, si je clique sur ce Calendrier LTS lien, il raconte une histoire différente. Pour autant que je sache, la version 6 de node.js est également prévue pour être une version LTS, avec une fin de support un an plus tard que la version 4.

Étant donné que :

• La v6.2.0 est une version numérotée.
• La v6 est censée bénéficier d'une maintenance LTS jusqu'au 2019-04-01.
• théoriquement aucun changement dans la v6.x ne doit rompre la rétrocompatibilité

Pourquoi prendre la peine de passer à la v4 au lieu de la v6 ? Il semble que la v4 m'offre une année de moins de correctifs de sécurité, mais aucune garantie de compatibilité supplémentaire ?

Answer 1

Avec toute notre gratitude à jasnell y TheAlphaNerd qui a patiemment répondu à mes questions acerbes sur GitHub, voici ce que je comprends de la façon dont les versions de node.js "support à long terme" sont gérées :

• Toutes les versions basées sur une branche majeure numérotée paire sont ce que d'autres projets pourraient appeler une version "support à long terme". On leur promet au moins 30 mois de support à partir de la première "coupe" mise à disposition (par exemple, une version packagée v6.0.0).

• Cependant, les mainteneurs de node.js considèrent que la "LTS" est plutôt une version phase qu'une version type . Bien qu'ils aient l'intention de rendre stables et rétrocompatibles les versions mineures/de correction réalisées lorsqu'une branche majeure est en phase d'amélioration active (voir "CURRENT" ci-dessous), dans le monde réel, ils peuvent faire des erreurs.

Ils divisent donc le développement en trois phases distinctes :

1. ACTUEL : nouvelles fonctionnalités (et corrections de bogues et correctifs de sécurité)
2. ACTIVE LTS : corrections de bogues (et correctifs de sécurité)
3. MAINTENANCE : uniquement les correctifs de sécurité

Les numéros impairs les versions majeures obtiennent seulement la première phase avant d'être laissé derrière. Les numéros pairs les versions majeures - celles qui nous intéressent le plus ici - passent par les trois phases .

La phase CURRENT commence avec la première version publique et fait démarrer le compte à rebours de la fenêtre de support de 30 mois. Elle peut ajouter de nouvelles fonctionnalités importantes, qui devraient en théorie être rétrocompatibles mais qui, en pratique, peuvent poser des problèmes (ajout d'un nouveau bug, modification d'un comportement mal défini, correction d'un ancien bug que vous aviez mal contourné, etc.)

Puis, à un moment donné, l'équipe décide de déplacer l'effort de développement principal vers une branche majeure impaire de courte durée (vraisemblablement lorsqu'elle a besoin de rompre intentionnellement la rétrocompatibilité). À ce moment-là, la branche paire passe à ACTIVE LTS et l'équipe fait beaucoup plus attention aux changements qu'elle apporte : il s'agit principalement de corrections de bogues. Donc, si vous voulez vraiment de la stabilité, c'est le moment d'adhérer à une version particulière.

Finalement, elle passe à la phase de MAINTENANCE, où le code n'est touché que pour les bogues les plus critiques (pensez aux correctifs de sécurité). Mais d'ici là, il y a probablement déjà une nouvelle version en "phase" LTS.

---

Ainsi, le choix sur la page d'accueil est actuellement entre deux branches à numérotation paire, "v4.4.5 LTS" et "v6.2.0 current". Si la branche la plus récente avait un numéro impair, alors il faudrait no être un bon candidat pour un déploiement en production où un soutien à long terme est souhaité.

Mes options actuelles sont un peu plus complexes encore :

Je pourrais simplement rester sur la v0.10 qui obtiendra les corrections critiques jusqu'en octobre. Ou passer à la v0.12 pour les obtenir jusqu'à la fin de l'année. Mais aucune de ces solutions ne m'apporte grand-chose, et je vais donc les écarter.

Je peux déployer la v4.4.5 qui reçoit encore des corrections de bogues en ce moment, et qui recevra des corrections de sécurité pendant un certain temps encore. Cela devrait me donner l'installation la plus stable. Le cycle de support est déjà à mi-chemin, cependant - et quand il se terminera, j'aurai manqué l'occasion de rattraper certains des changements majeurs qui ont déjà eu lieu dans les v5 et v6.

Je penche pour le déploiement de la version 6.2.0, en supposant que toutes mes dépendances la prennent en charge dès maintenant. Cela me permet non seulement d'avoir un an de plus de "cycle de vie restant", mais aussi de rattraper tous les changements qui ont été introduits entre la v0.10 et maintenant. (Cela me donne également accès à toutes les nouvelles fonctionnalités utiles - mais dans ce cas, je n'ai pas la chance d'en profiter). Le risque que je prends, c'est que lorsque je mets à jour vers une hypothétique v6.2.1 ou v6.3.0 ou au-delà qui se présente, cela pourrait accidentellement me réserver de mauvaises surprises.

Dans mon cas, je préfère m'occuper maintenant des changements intentionnels majeurs que la v5 et la v6 ont déjà introduits, et ensuite, si tout va bien, être prêt (ou au moins n'avoir que des douleurs mineures) jusqu'en avril 2019.