Node.js gibt das Ungerade/Gerade-Modell auf – so planen Sie jetzt Ihre Upgrades

Node.js ändert die Art und Weise, wie Major-Versionen veröffentlicht werden – und das mentale Modell, das jedes Backend-Team seit einem Jahrzehnt verwendet hat, verschwindet. Ab Version 27 wechselt das Projekt von zwei Major-Releases pro Jahr auf eines. Die Ungerade/Gerade-Regel, bei der ungerade Releases kurzlebig waren und gerade Releases zu Long-Term-Support wurden, wird abgeschafft. Jedes jährliche Release wird künftig LTS.

Der neue Rhythmus ist einfach. Ein Major erscheint jeweils im April, die LTS-Promotion folgt im Oktober desselben Jahres. Die Versionsnummern richten sich nach dem Kalenderjahr der ersten Current-Phase: 27.0.0 erscheint im April 2027, 28.0.0 im Jahr 2028 und so weiter. Neu hinzu kommt ein sechsmonatiger Alpha-Kanal von Oktober bis März, in dem Breaking Changes (Semver-Major) erlaubt sind und das Release-Team über CITGM die Testsuites populärer Pakete gegen die kommende Version ausführt. Node.js 26, das im Mai dieses Jahres erschienen ist, ist das letzte Release nach dem alten Modell. Der Alpha-Kanal für Node 27 öffnet im Oktober.

Was bedeutet das also konkret, wenn Sie Node im Produktivbetrieb einsetzen? Weniger als die Schlagzeile vermuten lässt – und genau das ist der Punkt.

Wenn Ihr Team bereits auf LTS-Versionen festlegt und die Current-Linie ignoriert, ändert sich kaum etwas außer der Versionsmathematik. Sie aktualisieren nach wie vor etwa alle zwei Jahre und erhalten weiterhin rund 30 Monate Support pro Linie. Wir haben zahlreiche langlebige Enterprise-Projekte auf diese Weise betrieben – insbesondere die Schweizer Compliance-Arbeit, bei der „langweilig und vorhersehbar“ ein Feature ist, keine Beschwerde. Die Abschaffung der Ungerade/Gerade-Regel beseitigt vor allem eine Art Überlieferung, über die neue Mitarbeiter stets gestolpert sind.

Die eigentliche Neuerung ist der Alpha-Kanal – und er richtet sich an eine Gruppe, zu der die meisten Teams vergessen, dass sie dazugehören: alle, die eine Bibliothek, ein SDK oder ein gemeinsam genutztes internes Paket pflegen. Jahrelang waren die ungeraden Releases die Stelle, an der Inkompatibilitäten zuerst auftauchten – und fast niemand hat dagegen getestet. Jetzt gibt es ein explizites sechsmonatiges Fenster von Oktober bis März, um Breaking Changes zu erkennen, bevor sie das LTS erreichen, auf das Ihre Kunden angewiesen sind. Aus unserer PHP- und Docker-Arbeit kennen wir dieses Muster aus anderen Ökosystemen: Das Problem liegt selten im Framework selbst, sondern in einer transitiven Abhängigkeit, die niemand gegen die Beta getestet hat. Ein jährlicher Alpha-Kanal gibt Ihnen ein festes Datum, um genau das herauszufinden.

Hier der konkrete Handlungsbedarf. Fügen Sie jetzt – noch vor Oktober – einen Node-Alpha-Job in Ihre CI ein, auch wenn er fehlschlagen darf. Ein einzelner Matrix-Eintrag, der Ihre Testsuite gegen die aktuelle Node-Alpha ausführt und Ergebnisse meldet, ohne den Build zu blockieren. Das kostet Sie einen zusätzlichen Job und verwandelt „unsere App ist mit dem neuen Node kaputt gegangen“ in ein Ticket, das Sie im November anlegen – statt in einen Brand, den Sie im darauffolgenden Frühjahr bekämpfen. Wenn Sie Pakete veröffentlichen, ist das kein Nice-to-have. So vermeiden Sie, die Abhängigkeit zu sein, die alle anderen bricht.

Ein Wort zu dem Upgrade-Reflex, den das fördert. Ein vorhersehbarer jährlicher Major ist gut, aber „vorhersehbar“ kann Teams in den Autopiloten wiegen. Das beobachten wir auch im Mobile-Bereich. Bei unseren nativen iOS- und Android-Projekten trainiert ein jährliches OS-Release Teams darauf, einen reibungslosen Wechsel zu erwarten – bis zu dem Jahr, in dem es das nicht ist. Behandeln Sie jeden Node-Major als echte Migration mit eigenem Testdurchlauf, nicht als bloße Formalie. Das Alpha-Fenster existiert genau deshalb, damit das April-Release langweilig sein kann.

Es gibt auch einen sicherheitsrelevanten Aspekt. Klarere Support-Zeiträume bedeuten, dass weniger Teams versehentlich eine abgekündigte Runtime betreiben, weil sie den Überblick verloren haben, welche Linie „gerade“ war und welche eine Sackgasse. Bei unseren Pentesting-Einsätzen ist eine nicht mehr unterstützte Node-Version einer der häufigeren Befunde – meist ein alter Dienst, für den niemand mehr zuständig ist. Dass jede Linie LTS wird, mit einem klaren 30-Monats-Countdown, macht aus „Laufen wir auf einer unterstützten Runtime?“ eine Ja/Nein-Frage statt eines Flussdiagramms. Tragen Sie das EOL-Datum noch heute in Ihren Dependency-Tracker ein.

Was mich immer wieder beschäftigt: Das ist Node, das eingesteht, dass die meisten Teams den Release-Rhythmus nie so genutzt haben, wie er gedacht war. Ein Major pro Jahr, jeder davon unterstützt, Inkompatibilitäten früh durch Alpha erkannt. Das ist weniger clever und dafür ehrlicher – und nach Jahren, in denen wir Kunden das Ungerade/Gerade-System erklärt haben, nehme ich das ehrlichere Modell gerne.

Wenn es Ihnen vertraut klingt, eine Flotte von Node-Diensten auf unterstützten, gut getesteten Runtime-Versionen zu halten, sprechen wir gerne darüber.