Durante mais de uma década, acompanhar as versões do Node.js exigiu decorar uma regra que parecia simples depois da terceira explicação: versões pares podiam chegar ao LTS, enquanto as ímpares tinham vida curta. A partir do Node.js 27, essa distinção deixa de existir. O projeto passará a lançar uma versão principal por ano, e toda versão principal seguirá para o suporte de longo prazo.
A mudança simplifica a numeração, mas não representa uma guinada brusca para quem já mantém aplicações em versões LTS. Na prática, essas equipes continuarão recebendo uma nova opção de LTS a cada ano. O impacto mais interessante está no caminho até essa versão estável, no trabalho de quem mantém bibliotecas e na redução do número de linhas que o próprio projeto precisa sustentar ao mesmo tempo.
Como funciona o calendário atual do Node.js
No modelo usado até o Node.js 26, o projeto abre duas linhas principais por ano. A versão par, lançada no primeiro semestre, passa cerca de seis meses como Current antes de ser promovida a LTS. A versão ímpar chega no segundo semestre, também permanece como Current por aproximadamente seis meses e depois alcança o fim de vida sem virar LTS.
Isso fez com que versões como 23 e 25 fossem úteis para testar novidades, compatibilidade e atualizações do V8, mas pouco atraentes para aplicações em produção. Muita gente simplesmente esperava a próxima versão par. Segundo o próprio projeto, as linhas ímpares tinham adoção mínima, confundiam usuários novos e ainda aumentavam o trabalho de manutenção.
O Node.js 26 é a última linha nesse formato. Ele foi lançado como Current em maio de 2026 e está previsto para entrar em LTS em outubro. Já o Node.js 27 inaugura o novo modelo: começa no canal Alpha em outubro de 2026, chega como Current em abril de 2027 e é promovido a LTS em outubro do mesmo ano.
O novo ciclo tem Alpha, Current e LTS
Com uma versão principal por ano, o ciclo passa a ter três fases mais explícitas:
- Alpha: dura cerca de seis meses, de outubro a março. Pode receber mudanças incompatíveis, usa versões como
27.0.0-alpha.1e serve para testes antecipados. - Current: começa em abril e dura outros seis meses. É o período de estabilização antes da promoção para LTS.
- LTS: começa em outubro e mantém uma janela semelhante à atual, com cerca de 30 meses de suporte de longo prazo.
O canal Alpha não é apenas outro nome para as builds noturnas. Seus lançamentos serão assinados, terão tags e passarão pelos testes do projeto, incluindo o CITGM, ferramenta usada para executar suítes de pacotes importantes do ecossistema contra uma nova versão do Node.js. Ainda assim, as APIs podem mudar entre alphas e o canal não é destinado à produção.
Essa fase cria uma janela mais organizada para experimentar alterações incompatíveis antes que uma versão seja declarada Current. Também dá aos autores de bibliotecas a chance de descobrir regressões com antecedência, em vez de receber a surpresa junto com todo mundo quando o LTS chegar. É aquele tipo de surpresa que costuma transformar uma atualização de rotina em uma tarde inteira olhando para logs.
Para aplicações em produção, muda menos do que parece
Quem já adota apenas versões LTS continuará com um ritmo anual de atualização. Antes, uma nova versão par chegava ao LTS a cada ano; agora, uma nova versão principal fará o mesmo. A janela de suporte também permanece próxima do que já existia, e o projeto preservará a sobreposição entre linhas LTS para permitir migrações planejadas.
A diferença mais visível é que a velha heurística de “par para produção, ímpar para experimentar” perde a validade. O Node.js 27 será ímpar e chegará ao LTS. Documentação interna, imagens de container, validadores de versão e automações que embutiram a regra antiga precisarão considerar o status real da linha, não a paridade do número.
Também não faz sentido interpretar o novo cronograma como sinal verde para instalar qualquer versão principal assim que ela aparecer. A recomendação oficial continua sendo usar versões Active LTS ou Maintenance LTS em produção. Alpha existe para teste antecipado; Current oferece acesso mais cedo à linha, mas ainda atravessa o período de estabilização.
Bibliotecas e ferramentas entram mais cedo na conversa
Para quem mantém pacotes npm, frameworks, ferramentas de build ou módulos nativos, o canal Alpha é a parte mais relevante da mudança. O projeto recomenda integrar essas versões ao CI o quanto antes. Se uma biblioteca testar somente versões LTS, uma incompatibilidade poderá ser descoberta tarde demais para influenciar a release que está prestes a chegar aos usuários.
Isso não significa transformar o Alpha na versão obrigatória da matriz principal. Um caminho mais equilibrado é criar uma execução separada e inicialmente tolerante a falhas, disparada por agenda, para acompanhar a próxima linha. Quando surgir uma regressão real, o mantenedor ganha tempo para isolar o problema, abrir uma issue e decidir se a correção pertence ao pacote ou ao Node.js.
Provedores de hospedagem, ferramentas de CI e imagens base também terão um ciclo mais previsível. Em vez de tratar versões ímpares como linhas descartáveis, o ecossistema pode se preparar sabendo que toda versão principal deverá atravessar Current e chegar ao LTS. Essa previsibilidade ajuda, mas não elimina o trabalho de testar dependências, addons nativos e mudanças do V8.
Por que reduzir de duas versões para uma
O argumento não é apenas simplificar a vida de quem escolhe uma versão para instalar. O Node.js é mantido principalmente por voluntários, e cada linha ativa aumenta o volume de backports, correções de segurança, testes e releases. Segundo o projeto, sustentar quatro ou cinco linhas simultaneamente tornou esse trabalho difícil de manter.
Concentrar esforços nas versões que as pessoas realmente usam pode melhorar a relação entre custo de manutenção e benefício para o ecossistema. Existe um preço: mudanças que exigem uma versão principal podem esperar mais tempo pelo próximo ciclo. Por outro lado, recursos compatíveis continuam podendo chegar em releases menores, e o projeto afirma que as versões recentes do V8 devem permanecer, no máximo, cerca de seis meses atrás do ciclo do motor.
Para equipes de produto, o recado mais útil é revisar a política de versões antes de outubro de 2026. Vale verificar se pipelines assumem que versões ímpares são temporárias, acompanhar o fim de vida da linha usada em produção e reservar testes para o Node.js 27 Alpha quando houver dependências sensíveis. Quem já trabalha com LTS e mantém upgrades regulares provavelmente verá pouca turbulência. Quem ainda depende da regra par ou ímpar vai precisar atualizar mais essa condição espalhada pelo projeto.