Was ist der Unterschied zwischen LTS und Current in Node.js?

Dieser Artikel stellt Ihnen den Unterschied zwischen LTS und Current in Node.js vor. Es hat einen gewissen Referenzwert. Freunde in Not können sich darauf beziehen. Ich hoffe, es wird für alle hilfreich sein.

Am 18. Oktober 2016 wurde Node.js v6 LTS (Boron) veröffentlicht. Dies ist auch das erste Mal seit dem Start des LTS-Releaseplans, dass zwei aktive LTS (v4 und v6) auf den Markt kamen zur gleichen Zeit. In dieser Artikelserie werden eine Reihe von Änderungen beschrieben, die durch Node.js v6 LTS verursacht wurden. Dieser Artikel konzentriert sich hauptsächlich auf LTS. Wenn der Leser mit dem Veröffentlichungsprozess von Node.js LTS noch nicht vertraut ist, können Sie zuerst diesen Artikel lesen. Andernfalls können Sie das Lesen des nächsten Artikels über Node.js Core-Änderungen überspringen.

Verwandte Empfehlungen: „nodejs-Tutorial“

Node.js LTS-Plan

Node.js-Kern Nach der Fusion von Node.js und io.js, um eine stabile und sichere Installation zu gewährleisten Ordnen Sie die Veröffentlichung so, dass Entwickler Upgrades sinnvoll arrangieren und mit der Nutzung von LTS (Long Term Support) beginnen können, um den Veröffentlichungszyklus zu planen. Die erste LTS-Version war v4 und wurde im Oktober 2015 veröffentlicht.

Unter 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 wird veröffentlicht. Daher basiert die Version von Node.js auf dem Lauf der Zeit und der Versionssprung erfolgt unter 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 scheint so schnell zu springen ( Es heißt nicht „Ah, wir haben so viele tolle Schritte gespeichert, wir können eine neue Version veröffentlichen!“, sondern „Ah, der April ist da und es ist Zeit, eine neue Version zu veröffentlichen. Sehen wir uns die großartigen Bewegungen an, die wir gespeichert haben, und schauen wir, ob es welche gibt, die stabil genug sind, um hinzugefügt zu werden. Auch wenn diese Tricks vielleicht nicht so groß sind ...“)

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 (Semantic Versioning). Die erste Nummer (semver-major) erhöht sich und zeigt die zweite Nummer (semver-minor) an ) wird erhöht, was darauf hinweist, dass es neue Funktionen gibt, 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. das Beheben von Fehlern oder die Verbesserung der Dokumentation. Diese Namensregel 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 aus, beispielsweise, wenn ein Sicherheitsupdate eine Inkompatibilität verursacht Um auf alle Hauptversionen zu aktualisieren, ist es immer noch eine Nebenversion.

Das Leben eines LTS. nummerierte Version (z. B. v6.0.0) als Alternative für das nächste LTS. Während des 6-Monats-Zeitraums von April bis Oktober dieses Jahres wird diese Version mit gerader Nummer als „aktuell“ bezeichnet (z. B. v6.0.0 „aktuell“). Nach Annahme des Feedbacks der Community werden in dieser Version Fehler behoben, neue Funktionen hinzugefügt und es werden möglicherweise auch einige Verbesserungen gelöscht, die große Auswirkungen auf die Kompatibilität haben. Derzeit wird die Anzahl der Nebenversionen dieser Version fortgesetzt erhöhen. Entwickler können diese Zeit nutzen, um ihre Anwendungen offline mit dieser LTS-Kandidatenversion zu testen und Kompatibilitätsprobleme und Fehler den Node.js-Entwicklern zu melden. LTS aktiv: Oktober des ersten Jahres bis April des dritten Jahres

Bis Oktober dieses Jahres wird diese gerade nummerierte Version zu LTS (z. B. v6.9.0 „LTS“), zu diesem Zeitpunkt wird sie auch aufgerufen „aktives LTS“. Während der nächsten 18 Monate der aktiven Nutzung wird es bei dieser Version fast nie inkompatible Änderungen geben, und andere Abhängigkeiten (z. B. v8) außer sicherheitsrelevantem OpenSSL werden keinen größeren Updates unterzogen. Während dieser Zeit können Entwickler online Node.js auf diese stabile LTS-Version aktualisieren und mit den neuen Funktionen von Node.js iterieren.

LTS-Wartung: April des dritten Jahres bis April des vierten Jahres

Nach 18 Monaten aktivem Zeitraum, im April des dritten Jahres, läutet diese Version die letzten 12 Monate des Wartungszeitraums ein. Zu diesem Zeitpunkt enthalten die Updates nur Sicherheitsupdates und Fehlerbehebungen. Da Node.js jedes Jahr im Oktober ein LTS veröffentlicht, wird während des aktiven Zeitraums dieser Version (derzeit, wenn v4 LTS noch 6 Monate aktiv ist, v6) ein neues aktives LTS auf 2/3 der Knoten geboren wenn LTS aktiv freigegeben wird). Bis zum Ende des aktiven Zeitraums hatten die Entwickler sechs Monate Zeit, um auf das nächste aktive LTS umzusteigen. Auch wenn Entwickler-Updates nur langsam voranschreiten, beträgt die Wartungszeit immer noch 12 Monate. Aktualisieren Sie daher so schnell wie möglich. Nach 12 Monaten endet dieses LTS seine Lebensdauer und erhält keine Updates mehr. Jede Version mit gerader Nummer hat also eine Lebensdauer von 3 Jahren.

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).

Entwickler, die v4.x noch online nutzen, können sich daher 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 ausgewählt 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 bei. 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.

Weitere Kenntnisse zum Thema Programmierung finden Sie unter: Programmiervideos! !

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