Долгое время правило было простым, и можно было сверяться с ним как с календарём: Node.js выпускал чётный major каждый апрель, нечётный - каждый октябрь, чётные становились LTS и жили годами, а нечётные тихо уходили в end-of-life примерно через полгода. Эта модель уходит. Начиная с Node.js 27 проект переходит на ежегодный цикл релизов, в котором каждая major-версия становится LTS после своей фазы Current, а нечётные линии перестают быть одноразовыми.[1]

Это важно, если вы деплоите Node на свой VPS, потому что до сих пор ваш ритм апгрейдов полностью определялся именно этой каденцией. Если вы хотели менять версию как можно реже, вы выбирали чётную LTS-линию и сидели на ней; нечётные Current-релизы были для тех, кому нужно самое новое. При новой схеме эта ментальная модель перестаёт работать: планирование апгрейдов становится вопросом «когда релиз готов», а не «какое у него число». Вот что именно меняется, сверено с официальными страницами в день написания.

Каденция, с которой вы жили

Чтобы понять, что меняется, стоит точно зафиксировать старую модель. Официальные релизные заметки описывают её так: исторически, вплоть до Node.js 26, нечётные релизы переставали поддерживаться через шесть месяцев, а чётные переходили в статус Active LTS и становились готовы к общему использованию.[1]

Конкретно это давало двухлетний ритм для каждой линии:

  • Чётный major (например 22, 24, 26): выходил в апреле, полгода Current, затем промоут в LTS и поддержка около 30 месяцев через фазы Active и Maintenance.
  • Нечётный major (например 21, 23, 25): выходил в октябре, полгода Current, затем end-of-life. Кандидатом в LTS никогда не был.

Итог: иногда поддерживались параллельно две чётные линии, что давало запас - можно было сидеть на чётном LTS, пока созревает следующая чётная линия. Нечётные Current-линии существовали, чтобы дать авторам библиотек и ранним последователям место для тестирования новых фич вне LTS-трека.

Что меняется с Node.js 27

Официальная страница релизов теперь гласит: «Starting with Node.js 27, the release cycle will be annual and every major version will move to LTS status after its six-month Current phase (and six additional months of Alpha phase)» - начиная с Node.js 27 цикл релизов станет ежегодным, и каждая major-версия перейдёт в статус LTS после своей шестимесячной фазы Current (и шести дополнительных месяцев фазы Alpha).[1]

Разберём это предложение на части, потому что важны обе половины:

  • Ежегодный цикл релизов. Major-версии теперь выходят раз в год, а не два раза. Чётно-нечётное чередование, при котором один релиз из двух был одноразовым, отменено.
  • Каждый major становится LTS. Пути «нечётный релиз умрёт через полгода» больше нет. Чётность числа больше не определяет судьбу линии. Каждая major получает полную LTS-обработку.

Окно поддержки - вторая заглавная цифра. На странице релизов сказано, что статус LTS «typically guarantees that critical bugs will be fixed for a total of 30 months» - обычно гарантирует исправление критических багов в течение суммарно 30 месяцев.[1] Эту 30-месячную гарантию и стоит закладывать в планирование деплоя: когда линия добралась до LTS, критичные фиксы ожидаются 30 месяцев, а для продакшена проект рекомендует только релизы Active и Maintenance LTS.[1]

Итак, форма жизни линии становится такой: Current, затем фаза Alpha, затем LTS (Active, потом Maintenance), причём на LTS-часть приходится 30-месячная гарантия поддержки.

Как текущий график выглядит сегодня

Конкретный переход удобнее всего увидеть по датам, которые уже опубликованы и стабильны. По состоянию на 12 октября 2026 года, согласно графику релизной рабочей группы:[2]

  • v26 вышел 5 мая 2026 и до сих пор в статусе Current; переходит в Active LTS 28 октября 2026, затем в Maintenance 20 октября 2027, end-of-life - 30 апреля 2029.
  • v24 (Krypton) был Active LTS до 20 октября 2026, после чего перешёл в Maintenance LTS; end-of-life - 30 апреля 2028.[2]
  • v22 (Jod) находится в Maintenance LTS и достигает end-of-life 30 апреля 2027.

Для v27 релизная рабочая группа уже начала публиковать график ежегодного цикла для новой линии в машиночитаемом schedule.json, а на странице рабочей группы стоит постоянная оговорка, что даты могут измениться.[2] Это первый major, запланированный по новой схеме, так что относитесь к датам перехода как к текущему плану проекта, а не к жёсткому обязательству, пока их не зафиксируют и линия реально не выйдет.

Что это значит непосредственно в день релиза: поддерживается сразу несколько линий, и именно это даёт вам решение при планировании апгрейда. Проект прямо говорит, что в продакшене стоит использовать только релизы Active LTS или Maintenance LTS.[1] Эта рекомендация не меняется.

Что это значит для деплоя Node на VPS

Если вы self-host’ите Node на VPS, практические вопросы такие: как часто придётся обновляться, когда планировать, и что с поддержкой безопасности. Вот честный разбор.

Больше не придётся ждать два года между «настоящими» релизами

При старой каденции релизы, которые люди реально деплоили, были чётными: примерно один в год, но фактически раз в два года, потому что каждый имел длинный хвост поддержки. Ежегодный цикл это схлопывает: каждый major теперь кандидат в LTS, так что новая прод-пригодная линия появляется раз в год вместо одного раза в два года «по безопасному треку». Даже если вы никогда не берёте Current или Alpha, выбирать между LTS-линиями приходится чаще.

Это не обязательно нагрузка. Смена каденции - изменение вместимости, а не требования: проект обещает, что каждый ежегодный major получит такую же длинную поддержку. Для вас частота обновлений по-прежнему во многом ваш выбор, потому что 30-месячное окно поддержки означает: вас никто не заставляет переезжать в день выхода нового major.

Планируйте апгрейды по Current-порогу

Самая полезная новая дисциплина - это порог Current. Major не рекомендуется для продакшена, пока не выйдет из Current в LTS, а это теперь происходит после шести месяцев Current плюс фаза Alpha.[1] Если ваш инстинкт - сидеть на поддерживаемой прод-линии, практическое правило такое: не берите новый major в первый же день. Пусть он переживёт периоды Current и Alpha, и целитесь в переход в LTS.

В одном смысле этот порог стал короче, чем раньше (теперь его проходит каждый major), а в другом - идентичен: брать нечётный major в старом мире для продакшена было всегда плохой идеей, и новый график полностью убирает эту ловушку. Не существует такой версии будущего, где линия гарантированно умрёт через полгода, потому что каждый major получает полную LTS-обработку.[1]

Поддержка безопасности меняется меньше всего

30-месячная гарантия поддержки для LTS-линий не сокращается.[1] Наоборот, новая модель - это обязательство, что ни один ежегодный major не является тупиком, так что предсказуемое окно исправления критических багов и проблем безопасности остаётся 30 месяцев на линию после достижения LTS.

Реальное соображение по безопасности - разрыв между релизом Current и LTS. В период Current и Alpha линия движется быстро, и её не стоит запускать для сервиса с открытым портом. Рекомендация проекта недвусмысленна: в продакшене используйте Active LTS или Maintenance LTS.[1] То есть ваша позиция по безопасности по-прежнему опирается на LTS-линии, а новая ежегодная каденция держит их поступление стабильным.

Практический план апгрейда для self-hosted приложения

Собираем вместе. Вот повторяемый подход для Node-приложения на одном VPS:

  1. Для всего, что наружу, сидите на LTS-линии. На сегодня это v24 (с 20 октября 2026 - Maintenance LTS, поддержка до 30 апреля 2028) или v26, когда он достигнет Active LTS 28 октября 2026.[2] v22 ещё поддерживается до 30 апреля 2027, если нужен запас, но он уже в Maintenance, так что приходят только критичные фиксы.[2]
  2. Следите за переходами Current-to-LTS, а не за датами релизов. Смотрите график релизной рабочей группы, когда линия реально достигает Active LTS, и планируйте переезд именно на этот момент. Для линий в полёте именно майские/октябрьские вехи решают, когда новый major безопасен для продакшена.[2]
  3. Не берите Current или Alpha в продакшен. В этих фазах новые фичи появляются и ломаются быстро; проект не зря направляет прод-пользователей на LTS-линии.[1] Хотите протестировать следующий major - поднимите черновой VPS или контейнер, но не основную машину.
  4. Перепроверяйте жизненный цикл версий перед сменой года. Поскольку LTS теперь становится больше линий, набор «поддерживаемых и стоящих внимания» версий меняется раз в год вместо одного раза в два. Быстрая проверка графика на ревью апгрейдов убережёт от планирования под линию, которая уже в end-of-life.

Всё это не требует учить новый инструмент или перенастраивать стек на VPS. Это изменение ментальной модели и календаря, а не того, как вы собираете и запускаете приложение. Бинарники, деплой, менеджер процессов и обратный прокси работают как раньше. Настраивается только то, когда вы планируете major-апгрейды и какое число вы считаете «безопасным».

Вывод

Node.js не ускоряет релизы так, чтобы заставлять вас обновляться быстрее. Он меняет то, какие релизы живут достаточно долго, чтобы иметь значение: начиная с v27 каждый ежегодный major получает полную LTS-обработку с 30-месячной гарантией поддержки после фаз Current и Alpha, вместо того чтобы хранителем был только каждый второй релиз.[1]

Для оператора VPS конкретные последствия скромные и управляемые. Держите для продакшена линию Active или Maintenance LTS, планируйте major-апгрейды вокруг перехода Current-to-LTS, а не вокруг анонса релиза, и раз в год перепроверяйте график жизненного цикла. Каденция, из-за которой каждые два года казались «большим» апгрейдом Node, теперь делает ежегодный апгрейд ежегодным - но с тем же длинным хвостом поддержки, на который можно приземлиться.

Источники

  1. Node.js - «Node.js Releases» (страница previous releases; формулировки: «Historically (up to Node.js 26), odd-numbered releases… become unsupported after six months, and even-numbered releases… move to Active LTS»; «Starting with Node.js 27, the release cycle will be annual and every major version will move to LTS status after its six-month Current phase (and six additional months of Alpha phase)»; «LTS… typically guarantees that critical bugs will be fixed for a total of 30 months»; «Production applications should only use Active LTS or Maintenance LTS releases»; v26 Current, вышла 2026-05-05, обновлена 2026-10-07). https://nodejs.org/en/about/previous-releases - проверено 2026-10-12
  2. Релизная рабочая группа nodejs/Release - график релизов и машиночитаемый schedule.json (v22: Maintenance, EOL 2027-04-30; v24 Krypton: Active LTS, Maintenance 2026-10-20, EOL 2028-04-30; v26: Current, Active LTS 2026-10-28, Maintenance 2027-10-20, EOL 2029-04-30; v27: первый major по ежегодной схеме, начальный график опубликован, даты могут измениться). https://github.com/nodejs/Release - проверено 2026-10-12