Node.js меняет правила игры для своей экосистемы: с октября 2026 года проект отказывается от схемы с двумя мажорными релизами в год и переходит на один. Для тех, кто следит за релизами Node.js не по диагонали, это не косметика в нумерации, а пересборка всего цикла обновлений: исчезает деление на «проходные» нечётные версии и «серьёзные» чётные, а каждая новая ветка будет доходить до статуса LTS.
Об изменении, как пишет InfoQ, команда Node.js объявила как о фундаментальном пересмотре релизной модели, которая держалась больше десяти лет. Новая схема стартует с Node.js 27: один мажорный релиз будет выходить каждый апрель, а в октябре та же ветка будет получать статус Long-Term Support. При этом нумерация теперь привязывается к календарному году первого Current-релиза, поэтому версия 27.0.0 выйдет уже в 2027 году, версия 28.0.0 — в 2028-м и так далее. Параллельно появится шестимесячный Alpha-канал для раннего тестирования, с prerelease-форматом вроде 27.0.0-alpha.1.
Главное последствие для рынка простое: все будущие релизы Node.js станут LTS, а различие между odd и even версиями исчезнет. Раньше проект жил по знакомой многим схеме: нечётные ветки выходили как краткоживущие и экспериментальные, а долгую поддержку получали только чётные. На бумаге это выглядело как баланс между скоростью и стабильностью. На практике корпоративные пользователи чаще всего просто игнорировали нечётные ветки, а мейнтейнерам всё равно приходилось тянуть их поддержку, переносить исправления и держать в голове несколько параллельных линий разработки.
Именно эта перегрузка и стала главным аргументом за реформу. История началась не вчера: предложение пересмотреть график релизов открыл в июле 2025 года участник Technical Steering Committee Node.js Рафаэль Гонзага. В обсуждении он описал проблему без особой романтики: сопровождение нескольких активных веток съедает силы релизной команды, особенно если часть версий почти не используется в продакшене. Для проекта, который во многом держится на сообществе и волонтёрской работе, это уже не вопрос эстетики процесса, а вопрос выживаемости модели поддержки.
Показательно, что за пересмотр старой схемы публично выступил и Джеймс Снелл, один из самых заметных участников core-команды Node.js и один из авторов прежнего релизного цикла. Его позиция звучит как редкий для больших инфраструктурных проектов момент здравого признания: модель, придуманная десять лет назад под тогдашние корпоративные циклы внедрения, просто устарела. Это хороший сигнал для экосистемы. Не потому, что Node.js внезапно стал любить перемены, а потому что проект перестал делать вид, будто потребности 2010-х автоматически подходят для 2027-го.
Впрочем, консенсус был не идеальным. В обсуждении на GitHub всплыл привычный конфликт интересов между крупными компаниями и командами, которые обновляются заметно быстрее. Кевин Лентин, описывая практику внутри большой корпорации, заметил, что его команда работает только на LTS, но при этом обновляется очень агрессивно: minor и patch-релизы попадают в dev почти сразу, затем быстро проходят через non-prod и в следующем спринте оказываются в production. Для таких команд даже год ожидания без обратного портирования новых возможностей выглядит болезненно. То есть Node.js не столько снял спор, сколько честно выбрал, в чью пользу сместить систему по умолчанию.
Для большинства компаний, особенно тех, кто и так живёт на LTS-ветках, драматических изменений не будет. Официальная позиция проекта довольно приземлённая: если вы уже обновляетесь только на LTS, для вас мало что меняется, кроме нумерации версий. Окно поддержки LTS остаётся примерно тем же — 30 месяцев. Зато сам график становится проще для планирования: один Current-релиз в апреле, одна LTS-промоция в октябре, меньше шума вокруг промежуточных веток, которые раньше приходилось учитывать хотя бы формально. Для IT-директоров и техлидов это почти подарок: проще синхронизировать дорожные карты, обновления платформы и внутренние compatibility checks.
Но есть и менее очевидный слой последствий — для авторов библиотек, фреймворков и внутренних платформ. Node.js прямо рекомендует как можно раньше включать Alpha-релизы в CI. Логика здесь жёсткая и вполне справедливая: если экосистема тестирует код только на LTS, баги всплывают слишком поздно — уже тогда, когда на новую ветку начинают смотреть реальные пользователи. На фоне популярности Express, Fastify, Next.js и десятков инфраструктурных пакетов это требование звучит не как совет, а как новая дисциплина. Иначе получается знакомая картина: платформа меняется по расписанию, а совместимость проверяется по факту, в режиме «ну теперь быстро чиним».
Отдельная деталь, которая может запутать даже опытных разработчиков: Node.js 26, вышедший в апреле 2026 года, станет последним релизом по старой схеме. Дальше начнётся переходный период с новым календарным ритмом, а версия 27 формально появится уже в 2027-м, хотя само изменение релизной политики вступает в силу в октябре 2026-го. Это тот редкий случай, когда номер версии перестаёт быть просто счётчиком и становится частью коммуникации о жизненном цикле продукта. Для команд, у которых автоматизация завязана на семантику мажорных веток, такую тонкость лучше учесть заранее, а не после первого вопроса от безопасников или закупок, почему «27» наступила не тогда, когда её ждали.
Вся эта история интересна не только самой Node.js. На фоне усложнения поддержки open source-платформ всё больше проектов пытаются сократить операционную нагрузку, не обрушив ожидания бизнеса. Если новая модель релизов Node.js действительно снизит стоимость сопровождения и одновременно сохранит предсказуемость для компаний, её почти наверняка начнут разбирать на части и примерять к себе соседние экосистемы. Тогда спор о количестве релизов быстро превратится в более неприятный, но и более полезный вопрос: сколько скоростных режимов сообщество вообще может себе позволить, прежде чем поддержка начнёт ломать сам продукт.