Quelle est la différence entre lts et current dans nodejs

Différence : Actuelle fait référence à la dernière version du nœud actuellement publiée, qui contient les dernières fonctionnalités, mais sera instable et sera mise à jour, optimisée ou corrigée de temps en temps ; tandis que LTS fait référence à la version du nœud prise en charge à long terme ; c'est-à-dire la version stable, les fonctions qu'elle contient sont stables.

L'environnement d'exploitation de ce tutoriel : système windows7, nodejs version 12.19.0, ordinateur DELL G3.

Allez sur le site officiel de nodejs pour télécharger https://nodejs.org Il existe deux versions, LTS et Current. Quelle est la différence ? Lequel dois-je choisir ? Bien entendu, si vous connaissez la différence, vous saurez quelle version choisir.

Résumé de la différence entre LTS et Current : En fait, vous pouvez dire à partir du numéro de version que l'une est nouvelle et l'autre est ancienne. La version actuelle est la dernière version et toutes les dernières fonctionnalités y sont présentes. C'est juste à vous d'essayer et de tester. Si tout le monde l'utilise bien et que la fonction est stable, elle sera publiée dans la version LTS. LTS est donc la version stable.

Ce qui suit est le plan de version de nodejs

Plan Node.js LTS

Node.js core Après la fusion de Node.js et io.js, afin d'assurer une version stable et ordonnée , laissez les développeurs Les développeurs peuvent organiser les mises à niveau de manière raisonnable et commencer à utiliser LTS (Long Term Support) 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é de la branche master qui a été stabilisée à un moment précis. Lorsque le temps sera écoulé, les parties stables de la branche master seront intégrées et une nouvelle version sera. Par conséquent, la sortie de Node.js est basée sur le passage du temps, le saut de version est basé 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 sortir une nouvelle version ! " mais " Ah, il est temps de sortir la nouvelle version en avril. Passons en revue les grands mouvements que nous avons enregistrés et voyez s'il y en a qui sont suffisamment stables pour être ajoutés. Ces astuces ne sont pas si grosses..."). 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 versionnement sémantique. Le numéro de version est divisé en trois parties. Le premier nombre (semver-major) augmente pour indiquer les modifications incompatibles ; le deuxième nombre (semver-minor) est augmenté, indiquant que. il y a de nouvelles fonctionnalités qui maintiennent la compatibilité ; le troisième numéro (semver-patch) est augmenté, indiquant qu'il y a des changements tout en maintenant la compatibilité et les fonctionnalités, comme la correction de bugs ou l'amélioration de la documentation. 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.

Comment choisir un développeur d'applications Node.js ?

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 que la version majeure est mise à niveau tous les 12 mois. a une durée de vie de 18 mois + 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 ne parvenez toujours pas à rattraper votre retard, vous devez au moins la mettre à niveau avant que cette version ne termine sa vie dans les 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 effectuer des tests hors ligne et préparer la mise à niveau à l'avance lorsque les versions paires sont publiées en avril de chaque année, et faire part des problèmes à la communauté (bien sûr, si vous n'avez pas le temps, vous n'avez pas à vous en soucier) Cette étape), et continuez à suivre et passez à la version en ligne en octobre. De cette manière, des mises à niveau majeures sont effectuées tous les 12 mois, en ligne et hors ligne, 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, par exemple, mises à jour v8 plus fréquentes (ce qui signifie davantage de mise en œuvre de nouvelles fonctionnalités ECMAScript et une optimisation des performances).

Par conséquent, les développeurs qui utilisent encore la v4.x en ligne peuvent déjà se préparer à 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 de 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 Github Repo de Node.js a une branche master, 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 récupérées par la personne responsable de la publication et fusionnées dans la version 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 branches liées aux autres versions sont la quintessence du mélange des commits sélectionnés dans le maître et adaptés à la version v6.x-staging conserve les modifications liées à v6.x LTS, et 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.

【Apprentissage recommandé : "Tutoriel Nodejs"】

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!