Was ist der Unterschied zwischen LTS und Current in NodeJS?

Unterschied: „Aktuell“ bezieht sich auf die aktuell veröffentlichte Knotenversion, die die neuesten Funktionen enthält, aber von Zeit zu Zeit aktualisiert, optimiert oder repariert wird, während sich „LTS“ auf die langfristig unterstützte Knotenversion bezieht ist die stabile Version, die darin enthaltenen Funktionen sind stabil.

Die Betriebsumgebung dieses Tutorials: Windows7-System, NodeJS-Version 12.19.0, DELL G3-Computer.

Gehen Sie zur offiziellen Website von nodejs, um https://nodejs.org herunterzuladen. Es gibt zwei Versionen, LTS und Current. Was ist der Unterschied? Welches soll ich wählen? Wenn Sie den Unterschied kennen, wissen Sie natürlich, welche Version Sie wählen müssen.

Zusammenfassung des Unterschieds zwischen LTS und Current: Tatsächlich können Sie anhand der Versionsnummer erkennen, dass das eine neu und das andere alt ist. „Current“ ist die neueste Version, in der alle aktuellen Funktionen enthalten sind. Es dient nur zum Ausprobieren und Testen. Wenn es von allen gut genutzt wird und die Funktion stabil ist, wird es für die LTS-Version freigegeben. LTS ist also die stabile Version.

Das Folgende ist der Versionsplan von nodejs.

Node.js LTS-Plan , damit Entwickler Upgrades sinnvoll arrangieren und LTS (Long Term Support) zur Planung des Release-Zyklus nutzen können. Die erste LTS-Version war v4 und wurde im Oktober 2015 veröffentlicht. Nach diesem Plan entspricht die Version von Node.js einem Snapshot des Master-Zweigs, der zu einem bestimmten Zeitpunkt stabilisiert wurde. Wenn die Zeit abgelaufen ist, werden die stabilen Teile des Master-Zweigs integriert und eine neue Version erstellt Daher basiert die Veröffentlichung von Node.js im Laufe der Zeit auf der Prämisse, eine enge Kompatibilität sicherzustellen, und nicht auf der Anzahl der Kompatibilitäten und neuen Funktionen. Dies erklärt auch, warum die Version von Node.js veröffentlicht wird .js scheint so schnell zu springen (nicht „Ah, wir haben so viele große Schritte gespeichert, wir können eine neue Version veröffentlichen!“), sondern „Ah, es ist Zeit, die neue Version im April zu veröffentlichen. Lassen Sie uns die großen Schritte durchgehen, die wir haben.“ gespeichert und sehen Sie, ob es welche gibt, die stabil genug sind, um hinzugefügt zu werden. Diese Tricks sind nicht so groß ...“). Es ist erwähnenswert, dass die aktuellen Evergreen-Browser/Mainstream-JavaScript-Engines/ECMAScript-Standards/C++-Standards ebenfalls ähnliche Prinzipien übernehmen, indem sie die Zeitspanne als Maßstab nehmen und stabile Funktionen aus dem Backbone für die Veröffentlichung abfangen. Jedes LTS hat einen Codenamen. Nehmen Sie den Elementnamen aus dem Periodensystem, sortieren Sie ihn alphabetisch und wählen Sie den entsprechenden aus. Der Codename von v4 ist Argon (Argon) und der Codename von v6 ist Boron (Bor).

Die Versionsbenennungsregeln von Node.js folgen der semantischen Versionierung. Die erste Nummer (Semver-Major) wird erhöht, was auf inkompatible Änderungen hinweist Es gibt neue Funktionen, die die Kompatibilität aufrechterhalten; die dritte Zahl (Semver-Patch) wird erhöht, was darauf hinweist, dass es Änderungen unter Beibehaltung der Kompatibilität und Funktionen gibt, wie z. B. die Behebung von Fehlern oder die Verbesserung der Dokumentation. Diese Benennungsregel hat Vor- und Nachteile, auf die ich hier nicht näher eingehen werde. Einige ihrer Widersprüche machen jedoch einige Ausnahmen bei der Benennung von Node.js, beispielsweise, selbst wenn ein Sicherheitsupdate eine Inkompatibilität verursacht Um auf alle Hauptversionen zu aktualisieren, ist es immer noch eine Nebenversion.

Wie wählt man Node.js-Anwendungsentwickler aus?

Für Node.js-Anwendungsentwickler, die Stabilität anstreben, müssen sie nur dann online nachverfolgen und aktualisieren, wenn eine Version jedes Jahr im Oktober aktiv wird. Das heißt, die Hauptversion wird immer noch alle 12 Monate aktualisiert hat eine Lebensdauer von 18 Monaten + 12 Monaten. Sie müssen sich nicht zu viele Gedanken über Kompatibilitätsprobleme machen, wenn Sie Minderjährige und Patches nachverfolgen. Die aktuelle Empfehlung lautet, dass es am besten ist, das Online-Upgrade innerhalb von 12 Monaten nach Veröffentlichung eines aktiven LTS abzuschließen (da das nächste aktive LTS nach 12 Monaten veröffentlicht wird). Wenn Sie im Verzug sind, können Sie bis 18 Monate vor dem Ende des aktiven Zeitraums dieses LTS einen Kompromiss eingehen. Wenn Sie immer noch nicht aufholen können, müssen Sie mindestens ein Upgrade durchführen, bevor diese Version innerhalb von 30 Monaten abläuft, andernfalls gibt es keine Sicherheitsupdates. Wenn Sie sich Sorgen über Kompatibilitätsprobleme machen, die beim direkten Upgrade auftreten, können Sie im Voraus Offline-Tests und Upgrade-Vorbereitungen durchführen, wenn die Version mit geraden Nummern jedes Jahr im April herauskommt, und die Probleme der Community mitteilen (natürlich, wenn Sie haben keine Zeit, Sie müssen sich darüber keine Sorgen machen) Dieser Schritt wird fortgesetzt und im Oktober wird auf die Online-Version aktualisiert. Auf diese Weise werden sowohl Online- als auch Offline-Studiengänge alle 12 Monate gefördert, die Zeitpunkte sind jedoch unterschiedlich. Obwohl es weitere Kompatibilitätsprobleme gibt, die offline weiterverfolgt werden müssen, können Sie Ihre Kompatibilitätsbedürfnisse auch durch Feedback von der Community berücksichtigen lassen.

Wenn Sie neue Funktionen ausprobieren möchten oder ein experimentelles Projekt sind, das nicht in einer Produktionsumgebung verwendet wird, können Sie die Hauptversionen mit ungeraden Nummern ausprobieren, die jedes Jahr im Oktober veröffentlicht werden. Jede Version mit ungerader Nummer wird nur 8 Monate lang gewartet und es gibt keine Kompatibilitätsgarantie wie bei LTS, aber Node.js-Entwickler werden diese Version verwenden, um sich auf das nächste LTS vorzubereiten, sodass es beispielsweise mutigere Versuche geben wird. häufigere v8-Updates (was mehr Implementierung neuer ECMAScript-Funktionen und Leistungsoptimierung bedeutet).

Daher können sich Entwickler, die v4.x noch online nutzen, bereits auf das Upgrade auf v6.x vorbereiten. Wenn Ihre Online-Anwendung immer noch eine Version verwendet, die vor dem Start des LTS-Plans veröffentlicht wurde, z. B. v0.12.x, ist es am besten, so bald wie möglich ein Upgrade auf v4.x oder höher durchzuführen, da v0.12.x dies nicht tun wird verfügbar nach Dezember 2016. Es wird keine Sicherheitsupdates geben, ganz zu schweigen von früheren Versionen. Der Hauptgrund dafür ist, dass OpenSSL-Schwachstellen nicht behoben werden und diese Anwendungen verschiedenen Sicherheitsrisiken ausgesetzt sind. Sobald Sie auf v4 aktualisieren.

Wie stimmt das mit dem Quellcode von Node.js überein?

Zuallererst verfügt das Github Repo von Node.js über einen Master-Zweig, und die meisten Commits werden über PR an diesen Zweig übermittelt. Je nachdem, ob diese Commits die Kompatibilität ändern oder neue Funktionen einführen, werden sie als Semver-Major oder Semver-Minor bezeichnet.

Wenn LTS jedes Jahr vor April vorbereitet werden muss, nimmt Node.js einen neuen Zweig vom Hauptzweig. Wenn es sich um Version 6 handelt, wird dieser Zweig als v6.x-Staging bezeichnet. Spätere Änderungen im Zusammenhang mit diesem LTS/Änderungen, die in dieses LTS aufgenommen werden sollen, wie z. B. Fehlerbehebungen usw., übermitteln weiterhin PR an den Master, Sie müssen jedoch ein Tag lts-watch-v6.x hinzufügen. Nach dem Zusammenführen in den Master werden diese Änderungen von der für die Veröffentlichung verantwortlichen Person übernommen und in das v6.x-Staging eingefügt. Wenn eines Tages im April die erste Version von v6 zur Veröffentlichung bereit ist, erstellt die für die Veröffentlichung verantwortliche Person einen v6.x-Zweig und führt die Änderungen aus dem v6.x-Staging zusammen. Von April bis Oktober werden alle Änderungen an Version 6, egal ob Nebenversion oder Patch, immer noch zuerst an den Master übermittelt, dann ausgewählt und im v6.x-Staging zusammengeführt und dann in v6.x eingegeben, wenn die Version veröffentlicht wird. Auf diese Weise behält der Master immer die neuesten Änderungen. Die mit anderen Versionen verbundenen Zweige sind der Inbegriff für die Mischung der aus dem Master ausgewählten und für die Release-Version geeigneten Commits. Die Version v6.x behält die LTS-bezogenen Änderungen von v6.x bei, und v6.x behält die Version jeder Version der Version 6 bei. . Mit Ausnahme der Person, die für die Verwaltung des Zweigs verantwortlich ist, werden andere Entwickler diese versionierten Zweige nicht berühren.

【Empfohlenes Lernen: „nodejs-Tutorial“】

Das obige ist der detaillierte Inhalt vonWas ist der Unterschied zwischen LTS und Current in NodeJS?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!