Node.js 27 i jedno wydanie rocznie: co z wersjami 22, 24 i 26

Jedna wersja główna rocznie i każda z LTS

Od dziesięciu lat Node.js wydawał dwie wersje główne rocznie. Wersja parzysta wychodziła w kwietniu i w październiku dostawała status LTS. Wersja nieparzysta wychodziła w październiku, żyła ok. 8 miesięcy i nigdy nie dostawała LTS. Linia LTS miała 12 miesięcy aktywnego wsparcia i 18 miesięcy fazy Maintenance, w której trafiały do niej głównie poprawki bezpieczeństwa i krytyczne błędy.

Od Node.js 27 projekt wydaje jedną wersję główną rocznie. Cykl każdej linii wygląda tak:

• Alpha (październik–marzec): wydania testowe w formacie 27.0.0-alpha.1, podpisane i testowane, ale z dopuszczonymi zmianami łamiącymi zgodność. Nie są przeznaczone na produkcję.
• Current (kwiecień–październik): pierwsza wersja stabilna, czas na dopracowanie.
• LTS (30 miesięcy): od października, bez podziału na Active i Maintenance.

Od pierwszego wydania Current do końca wsparcia mija 36 miesięcy. Nie będzie już linii nieparzystych bez LTS, a numer wersji odpowiada rokowi wydania: 27.0.0 w 2027, 28.0.0 w 2028. Projekt opublikował nowy model wiosną 2026 r. i zastrzega, że daty mogą się jeszcze zmienić. Teraz zaczyna on działać w praktyce: 28 października startuje Alpha Node.js 27, a Node.js 26 dostaje LTS.

Daty dla linii, których dziś używacie

• Node.js 22: w fazie Maintenance od października 2025 r., koniec wsparcia 30 kwietnia 2027.
• Node.js 24: w fazie Maintenance od 20 października 2026 r., koniec wsparcia 30 kwietnia 2028.
• Node.js 26: ostatnia linia według starych zasad. LTS od 28 października 2026, Maintenance od 20 października 2027, koniec wsparcia 30 kwietnia 2029.
• Node.js 27: Alpha od 28 października 2026, Current od 22 kwietnia 2027, LTS od 20 października 2027, koniec wsparcia 30 kwietnia 2030.

Linie 22, 24 i 26 dokończą swój cykl bez zmian. Nowe zasady obejmują wersje od 27 w górę.

Node.js 18 i 20 to już tylko ryzyko

Node.js 18 stracił wsparcie 30 kwietnia 2025 r., a Node.js 20 rok później, 30 kwietnia 2026 r. Bez wsparcia są też linie nieparzyste 23 i 25. Te wersje nie dostają żadnych poprawek. Dobrze to widać na wydaniu bezpieczeństwa z 21 października, które opisujemy w osobnym wpisie: poprawki dostały linie 22, 24 i 26, a 18 i 20 pozostają podatne. Projekt Node.js zwraca uwagę na dodatkowe skutki: popularne pakiety stopniowo porzucają stare wersje, a audyty zgodności często wprost zabraniają runtime’u bez wsparcia.

Jeśli migracji nie da się zrobić od razu, OpenJS Foundation wskazuje płatne wsparcie dla wersji EOL (HeroDevs, NodeSource, TuxCare). To rozwiązanie przejściowe, które kupuje czas na przejście na wspieraną wersję.

Na którą wersję przechodzić teraz

• Nowe wdrożenia i aplikacje na 18/20: celujcie w Node.js 26. Za kilka dni dostanie status LTS ze wsparciem do kwietnia 2029.
• Aplikacje na 22: zostało pół roku. Zaplanujcie migrację na 26 (ewentualnie 24) na najbliższe miesiące, z zapasem przed kwietniem 2027.
• Aplikacje na 24: mają czas do kwietnia 2028. Przejście na 26 lub 27 zaplanujcie na 2027 rok.
• Node.js 27 nie nadaje się na produkcję przed kwietniem 2027. Alpha służy do testów.

Kalendarz aktualizacji w nowym rytmie

Od 2027 r. nowa wersja LTS pojawia się co roku w październiku i ma 30 miesięcy wsparcia. Najprostszy plan to jedna migracja rocznie: między październikiem a marcem przechodzicie na najnowszą wersję LTS, gdy pierwsze poprawki już do niej trafiły. Firmy, które aktualizują rzadziej, mogą przeskakiwać co drugą wersję, np. z 28 na 30. Na migrację zostaje wtedy ok. 6 miesięcy między startem nowego LTS a końcem starego, więc termin warto mieć wpisany w kalendarz na stałe.

Gdzie sprawdzić, na jakiej wersji jesteście

• Serwery i stacje: node -v, a w projektach pole engines w package.json oraz pliki .nvmrc i .node-version.
• Obrazy Docker: grep -rn "FROM node" . w repozytoriach. Przypinajcie wersję główną (np. node:26-bookworm-slim) zamiast node:latest albo node:lts, bo tagi ruchome zmienią wersję główną przy kolejnym budowaniu bez Waszej decyzji. Po zmianie obrazu bazowego samo podbicie tagu nie wystarczy: przebudujcie obrazy.
• CI: w macierzach testów (np. node-version w GitHub Actions) zostawcie wspierane linie LTS i usuńcie 18 i 20. Zespoły, które utrzymują własne biblioteki, mogą dodać Alpha jako zadanie, które nie blokuje budowania. Projekt Node.js zaleca to wprost, żeby błędy wychodziły przed wydaniem stabilnym.
• Aplikacje dostawców: aplikacje na Electronie i część produktów komercyjnych mają wbudowany własny Node.js, którego nie zaktualizujecie sami. Zapytajcie dostawców, na jakiej linii stoją i kiedy przejdą na wspieraną wersję.

Co z tego wynika na dłużej

Dla firm, które i tak instalują tylko wersje LTS, zmienia się głównie numeracja i to, że nowa wersja LTS przychodzi raz w roku o stałej porze. Stały termin ułatwia planowanie, ale wymaga spisu: gdzie działa Node.js, w jakiej wersji i kto odpowiada za jego podniesienie. Firmy, które mają taki spis, traktują każdą zmianę wersji jako zwykłe zadanie w rocznym planie, bez pośpiesznej migracji po kolejnym wydaniu bezpieczeństwa.