Quelle est la différence entre LTS et Current dans Node.js

Cet article vous présentera la différence entre LTS et Current dans Node.js. Il a une certaine valeur de référence. Les amis dans le besoin peuvent s'y référer. J'espère qu'il sera utile à tout le monde.

Le 18 octobre 2016, Node.js v6 LTS (Boron) est sorti. C'est également la première fois depuis que Node.js a lancé le plan de publication LTS que deux sont actifs. LTS (v4 et v6). Cette série d'articles décrira une série de changements apportés par Node.js v6 LTS. Cet article se concentre principalement sur LTS. Si les lecteurs ne sont toujours pas familiers avec le processus de publication de Node.js LTS, vous pouvez d'abord lire cet article. Sinon, vous pouvez ignorer la lecture de l'article suivant sur les modifications apportées à Node.js Core.

Recommandations associées : "Tutoriel Nodejs"

Plan LTS Node.js

Le noyau de Node.js a commencé à utiliser LTS (Support à long terme ) pour planifier le cycle de publication. La première version LTS était la v4, publiée en octobre 2015.

Dans ce plan, la version de Node.js équivaut à un instantané stable de la branche master à un moment précis. Lorsque le temps sera écoulé, les parties stables de la branche master seront intégrées et une nouvelle. La version sera publiée.Par conséquent, la sortie de Node.js est basée sur le passage du temps, et la version saute sur le principe d'assurer une compatibilité étroite, plutôt que sur le nombre de compatibilités et de nouvelles fonctionnalités. Cela explique également pourquoi la version de. Node.js semble sauter si vite (pas "Ah, nous avons sauvé tellement de gros mouvements, nous pouvons publier une nouvelle version!" mais "Ah, il est temps de sortir une nouvelle version en avril. Passons en revue les grands mouvements. nous avons sauvegardé pour voir ce qui est suffisamment stable, même si ces astuces ne sont peut-être pas si importantes...").

Il convient de mentionner que les navigateurs persistants actuels/les moteurs JavaScript grand public/les normes ECMAScript/les normes C++ adoptent également des principes similaires, prenant le laps de temps comme référence et interceptant les fonctionnalités stables du backbone pour la publication.

Chaque LTS aura un nom de code. Prenez le nom de l'élément du tableau périodique, triez-le par ordre alphabétique et sélectionnez celui qui convient. Le nom de code de la v4 est Argon (argon) et le nom de code de la v6 est Boron (bore).

Les règles de dénomination des versions de Node.js suivent le Semantic Versioning (Semantic Versioning). Le numéro de version est divisé en trois parties. Le premier nombre (semver-major) augmente pour indiquer une incompatibilité. . changements ; le deuxième nombre (semver-minor) augmente, indiquant qu'il existe de nouvelles fonctionnalités qui maintiennent la compatibilité ; le troisième nombre (semver-patch) augmente, indiquant qu'il y a des changements tout en maintenant la compatibilité et les fonctionnalités inchangées, telles que Bugs corrigés ou documentation améliorée. Cette règle de nommage présente des avantages et des inconvénients, que je ne détaillerai pas ici. Cependant, certaines de ses contradictions font quelques exceptions au nommage de Node.js, même si une mise à jour de sécurité provoque une incompatibilité, afin de pouvoir le faire. pour mettre à jour vers toutes les versions majeures, c'est toujours semver -minor.

Vie d'un LTS

LTS actuel : avril à octobre de la première année

Actuellement, Node.js quittera master chaque mois d'avril, collectera suffisamment de fonctionnalités stables et publiera une version majeure à numéro pair (telle que la v6.0.0) comme alternative pour la prochaine LTS. Durant la période de 6 mois allant d'avril à octobre de la même année, cette version paire est dite « actuelle » (par exemple, v6.0.0 « actuelle »). Après avoir accepté les commentaires de la communauté, cette version corrigera les bugs, ajoutera de nouvelles fonctionnalités, continuera à s'améliorer et pourra également supprimer certaines améliorations qui ont un impact trop important sur la compatibilité. À l'heure actuelle, la version mineure de cette version continuera à augmenter. Les développeurs peuvent profiter de ce temps pour tester leurs applications hors ligne avec cette version candidate LTS et signaler les problèmes de compatibilité et les bugs aux développeurs Node.js.

LTS actif : octobre de la première année à avril de la troisième année

D'ici octobre de la même année, cette version paire deviendra LTS (comme la v6.9.0 "LTS") , Il est également appelé « LTS actif » à l'heure actuelle. Au cours des 18 prochains mois d'utilisation active, cette version ne comportera presque jamais de modifications incompatibles, et les autres dépendances (telles que la v8) autres que OpenSSL liées à la sécurité ne subiront pas de mises à jour majeures. Pendant cette période, les développeurs peuvent mettre à niveau Node.js en ligne vers cette version LTS stable et itérer en utilisant les nouvelles fonctionnalités de Node.js.

Maintenance LTS : avril de la troisième année à avril de la quatrième année

Après 18 mois de période active, en avril de la troisième année, cette version inaugurera les 12 derniers mois de la période de maintenance. Pour le moment, ses mises à jour n'incluront que des mises à jour de sécurité et des corrections de bugs. Puisque Node.js publie un LTS en octobre de chaque année, un nouveau LTS actif naîtra sur 2/3 des nœuds pendant la période active de cette version (actuellement, lorsque la v4 LTS a 6 mois pour être actif, la v6 Le point temporel lorsque LTS actif est libéré). À la fin de sa période active, les développeurs disposaient de 6 mois pour passer au prochain LTS actif. Même si la progression des mises à jour des développeurs est lente, il reste encore 12 mois de maintenance, alors effectuez la mise à niveau dès que possible. Au bout de 12 mois, cette LTS mettra fin à sa vie et ne recevra plus aucune mise à jour. Ainsi, chaque version paire a une durée de vie de 3 ans.

Comment les développeurs d'applications Node.js choisissent-ils ?

Pour les développeurs d'applications Node.js qui recherchent la stabilité, il leur suffit de suivre et de mettre à niveau en ligne lorsqu'une version devient active LTS en octobre de chaque année, c'est-à-dire tous les 12. La version majeure est mis à jour une fois par mois et chaque version mise à niveau a une durée de vie de 18 + 12 mois. Vous n'avez pas à vous soucier trop des problèmes de compatibilité lors du suivi des mineurs et des correctifs. La recommandation actuelle est qu'il est préférable de terminer la mise à niveau en ligne dans les 12 mois suivant la sortie d'un LTS actif (car le prochain LTS actif sera publié après 12 mois). Si vous êtes en retard, vous pouvez faire des compromis jusqu'à 18 mois, avant la fin de la période active de cette LTS. Si vous n'arrivez pas à rattraper votre retard, vous devez au moins la mettre à jour avant la fin de vie de cette version dans un délai de 30 mois, sinon il n'y aura pas de mises à jour de sécurité.

Si vous êtes préoccupé par les problèmes de compatibilité rencontrés par la mise à niveau directe, vous pouvez tester et mettre à niveau hors ligne à l'avance lorsque la version paire sort chaque avril, et faire part du problème à la communauté (bien sûr, si vous n'avez pas le temps) Il n'y a pas lieu de s'inquiéter de cette étape), et continuez à suivre et passez à la version en ligne en octobre. De cette manière, les majors en ligne et hors ligne sont promues une fois tous les 12 mois, mais les moments sont différents. Bien qu'il existe davantage de problèmes de compatibilité qui doivent être suivis hors ligne, vous pouvez également faire en sorte que vos besoins de compatibilité soient pris en charge par la communauté via des commentaires.

Si vous souhaitez essayer de nouvelles fonctionnalités, ou si vous êtes un projet expérimental qui n'est pas utilisé dans un environnement de production, vous pouvez essayer les versions majeures impaires publiées chaque mois d'octobre. Chaque version impaire ne sera maintenue que pendant 8 mois et il n'y aura aucune garantie de compatibilité comme LTS, mais les développeurs Node.js utiliseront cette version pour préparer le prochain LTS, il y aura donc des tentatives plus audacieuses. des mises à jour v8 plus fréquentes (ce qui signifie davantage d'implémentations de nouvelles fonctionnalités ECMAScript et d'optimisations de performances).

Par conséquent, les développeurs qui utilisent encore la v4.x en ligne sont désormais prêts à passer à la v6.x. Si votre application en ligne utilise toujours une version publiée avant le lancement du plan LTS, telle que la v0.12.x, il est préférable de mettre à niveau vers la v4.x ou une version ultérieure dès que possible, car la v0.12.x ne sera pas disponible. disponible après décembre 2016. Il n'y aura pas de mises à jour de sécurité, encore moins les versions antérieures. La raison principale est que les vulnérabilités d'OpenSSL ne seront pas corrigées et que ces applications seront exposées à divers risques de sécurité. Une fois la mise à niveau vers la v4.

Comment cela correspond-il au code source de Node.js ?

Tout d'abord, le dépôt Github de Node.js a une branche principale, et la plupart des commits sont soumis à cette branche via PR. Selon que ces commits modifient la compatibilité ou introduisent de nouvelles fonctionnalités, ils sont étiquetés semver-major ou semver-minor.

Lorsque LTS doit être préparé avant avril de chaque année, Node.js prendra une nouvelle branche de la branche principale. S'il s'agit de la v6, alors cette branche est appelée v6.x-staging. Les modifications ultérieures liées à ce LTS/modifications destinées à entrer dans ce LTS, telles que les corrections de bugs, etc., soumettent toujours PR au maître, mais vous devez ajouter une balise lts-watch-v6.x.

Après avoir été fusionnées dans master, ces modifications seront sélectionnées par la personne responsable de la publication et fusionnées dans la v6.x-staging. Lorsque la première version de la v6 sera prête à être publiée un jour d'avril, la personne responsable de la publication créera une branche v6.x et fusionnera les modifications de la mise en scène v6.x. D'avril à octobre, toutes les modifications apportées à la v6, qu'elles soient mineures ou correctives, sont toujours soumises d'abord au maître, puis sélectionnées et fusionnées dans la mise en scène v6.x, puis saisies dans la v6.x lorsque la version est publiée.

De cette façon, le maître conserve toujours les dernières modifications. Les autres branches liées à la version sont des microcosmes de mélange et de sélection de commits adaptés à la publication à partir du maître. La mise en scène v6.x conserve les modifications liées à la version v6.x LTS, et la version v6.x conserve la version de chaque version v6. À l'exception de la personne responsable de la gestion de la branche, les autres développeurs ne toucheront pas à ces branches liées aux versions.

Pour plus de connaissances sur la programmation, veuillez visiter : Vidéo de programmation ! !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!