Pourquoi node.js v4.4.5 est-il recommandé plutôt que v6.2.0 "pour la plupart des utilisateurs"?
J'ai utilisé node.js pour un projet de développement il y a quelques années et cette application est quelque peu "bouchée" pour le moment. Elle doit rester en ligne, elle doit rester sécurisée, mais elle ne devrait pas nécessiter beaucoup d'attention. Il fonctionne actuellement sur node.js v0.10.32, mais j'aimerais maintenant investir dans une migration "finale" vers une version de support à long terme (LTS) afin de faciliter sa maintenance dans un avenir proche.
À première vue, la page d'accueil de node.js donne à penser que la v4.4.5 est évidemment la seule version disponible de LTS:
Cependant, si je clique sur ce lien calendrier LTS , il raconte une histoire différente. Autant que je sache, la version 6 de node.js devrait également être une version LTS, cette prise en charge prenant fin un an plus tard que la version 4.
Étant donné que:
- v6.2.0 est une version versionnée
- la v6 est censée recevoir la maintenance LTS jusqu'en 2019-04-01
- théoriquement aucune modification de la version 6.x ne devrait rompre la compatibilité avec les versions antérieures
Pourquoi devrais-je prendre la peine de passer à la v4 au lieu de la v6? On dirait que la v4 m'achète un an de moins de correctifs de sécurité, mais aucune garantie de compatibilité supplémentaire?
Avec gratitude envers jasnell et TheAlphaNerd qui ont patiemment répondu à mes questions acerbes sur GitHub, voici comment je comprends comment les versions de "support à long terme" de node.js sont traitées:
Toutes les versions basées sur une branche principale paire sont ce que d'autres projets pourraient appeler une version "support à long terme". On leur promet d’être soutenus au moins 30 mois à compter de la première mise à disposition (par exemple, des versions v6.0.0 packagées).
Cependant, les responsables de node.js voient "LTS" plus comme une version phase que comme une version type . S'ils souhaitent des versions mineures/correctives apportées lorsqu'une branche majeure est en phase d'amélioration active (voir "ACTUEL" ci-dessous) pour être stable et compatible avec les versions antérieures, ils peuvent commettre des erreurs dans le monde réel.
Donc, ils divisent le développement en trois phases distinctes :
- ACTUEL: nouvelles fonctionnalités (corrections de bugs et correctifs de sécurité)
- ACTIVE LTS: corrections de bugs (et correctifs de sécurité)
- MAINTENANCE: uniquement des correctifs de sécurité
Les versions majeures à numéro impair ne reçoivent que la première phase avant d'être laissées pour compte . Les versions majeures qui nous intéressent le plus ici sont numérotées paires - passent par les trois phases .
La phase CURRENT commence avec la première publication publique et commence le compte à rebours sur la fenêtre de support après 30 mois. Ils peuvent ajouter d’importantes nouvelles fonctionnalités, qui devraient en théorie être rétrocompatibles, mais dans la pratique, certains problèmes peuvent survenir (ajout d’un nouveau bogue, modification du comportement mal défini, correction d’un ancien bogue sur lequel vous avez mal travaillé, etc.). )
Puis, à un moment donné, l’équipe décide de déplacer l’effort de développement principal vers une branche principale de courte durée, à nombre impair, (vraisemblablement au moment où elle doit volontairement mettre fin à la compatibilité en amont). À ce stade, la branche numérotée passe à ACTIVE LTS et devient beaucoup plus prudente avec les modifications apportées: il s'agit principalement de corrections de bugs. Donc, si vous voulez vraiment de la stabilité, c'est le moment de vous "embarquer" avec une version particulière.
Finalement, il passe encore plus loin à la phase MAINTENANCE, où le code n'est touché qu'en réponse aux bogues les plus critiques (pensez: correctifs de sécurité). Mais d'ici là, il y a probablement une nouvelle version de LTS "phase" déjà.
Le choix sur la page d’accueil se situe donc actuellement entre deux branches paires, "v4.4.5 LTS" et "v6.2.0 actuelle". Si la branche la plus récente portait un numéro impair, alors ne serait pas un bon candidat pour un déploiement en production où une assistance à long terme est souhaitée.
Mes options actuelles sont un peu plus complexes même:
Je pourrais simplement rester sur la v0.10, qui apportera des corrections critiques jusqu'en octobre. Ou passez à la v0.12 pour les obtenir jusqu'à la fin de l'année. Mais ni l’un ni l’autre ne m’apporte grand chose et je les écarterai donc.
Je peux déployer la v4.4.5 qui obtiendra toujours des corrections de bugs généraux pour le moment et des corrections de sécurité pour un bon bout de temps encore. Cela devrait me donner l'installation la plus stable. Le cycle de soutien commence déjà à être à moitié terminé - et quand il sera épuisé, j'aurai manqué l'occasion de rattraper certains des changements majeurs déjà intervenus dans les versions 5 et 6.
Je suis enclin à déployer la version 6.2.0, en supposant que toutes mes dépendances le supportent maintenant. Cela ne me permet pas seulement de gagner un an de "cycle de vie restant", mais me permet également de me familiariser avec tous les changements radicaux introduits entre la v0.10 et la version actuelle. (Cela me donne également accès à de nouvelles fonctionnalités utiles - mais dans ce cas, je n’ai pas la chance de pouvoir en tirer parti.) Le risque que je prends est que lorsque je mets à jour une version hypothétique v6.2.1 ou v6.3.0 ou au-delà, cela pourrait donner accidentellement de mauvaises surprises.
Dans mon cas, je préférerais maintenant parler des changements intentionnels majeurs déjà introduits par la v5 et la v6, puis, espérons-le, être tous prêts (ou du moins que peu douloureux) d’ici avril 2019.