Evolving the Node.js Release Schedule

Node.js давно загнала себя в странное состояние — чётные релизы становились LTS с поддержкой в 3 года, а нечётные имели очень короткий срок жизни — 9 месяцев. Нечётные релизы помогали команде быстрее итерироваться, мёрджить экспериментальные фичи. Но в конечном счёте все эти фичи всегда попадали и в чётные релизы.

Возможно из-за этого нечётные релизы прославились «нестабильными». Мне кажется они никогда такими не являлись и если явно указывать версию nodejs через .nvmrc (а я считаю что нужно это делать в любом проекте, даже если вы работаете над ним один), то это помогало избежать проблем. Но из-за ощущения «нестабильности» и короткой жизни релиза нечётные релизы не пользовались популярностью — все использовали чётные версии.

Здесь возникает логичный вопрос. У вас есть «экспериментальные» релизы, фичи из которых хочется протестировать на реальных людях, собрать фидбек, поправить баги и уже после этого спокойно слить в LTS версию. Как всё это делать, если пользователей толком нет?

C октября 2026 года всё поменяется:
1. Один мажорный релиз каждый апрель
2. Релиз становится LTS в октябре
3. Появятся альфа-версии для изменений, ломающих обратную совместимость
4. Версия ноды совпадает с годом релиза (26 в 2026, 27 в 2027 — привет Apple)

Очень правильный шаг, который позволит в том числе и снизить нагрузку на релизеров ноды.

Подробнее тут https://nodejs.org/en/blog/announcements/evolving-the-nodejs-release-schedule

Ну и если вам интересно как принималось решение:
https://github.com/nodejs/Release/issues/1113
https://github.com/nodejs/nodejs.org/pull/8631