Node.js 26 é o fim de uma era: a partir do 27, uma major por ano

A última versão do modelo antigo

O Node.js 26 entrou como versão Current trazendo o V8 na 14.6 e a API Temporal habilitada por padrão — a substituição definitiva do velho objeto Date, que atormentou uma geração inteira de desenvolvedores JavaScript com fusos, meses indexados em zero e comparações que só funcionavam por acidente.

Mas a notícia estrutural não é a API nova. É que o Node 26 é a última versão a seguir o modelo de lançamento atual. A partir do Node 27, em outubro de 2026, o projeto passa a uma cadência anual: uma major por ano, e só.

Por que a cadência importa mais que o changelog

O modelo vigente entregava duas majors por ano, uma em abril e outra em outubro, com a de números pares entrando em LTS. Na teoria, dava previsibilidade. Na prática, produziu um efeito colateral conhecido em qualquer time que mantém aplicação em produção há mais de três anos: a matriz de versões suportadas ficou grande demais.

Biblioteca precisava testar contra Current, Active LTS e Maintenance LTS ao mesmo tempo. Imagem Docker acumulava variantes. Pipeline de CI rodava a mesma suíte em três runtimes para pegar uma incompatibilidade que aparecia em um só. E o time de produto vivia adiando a atualização porque a janela entre uma major e a seguinte nunca dava conforto.

Uma major por ano reduz esse custo em todos os pontos ao mesmo tempo. Menos versões vivas, menos combinação de teste, menos decisão de migração por ano.

O que muda no planejamento de quem mantém sistema

Três consequências práticas valem entrar no calendário de qualquer time que roda Node em produção.

A primeira: a janela de atualização deixa de ser semestral e vira anual. Isso é bom para estabilidade e ruim para quem procrastina — pular uma major agora significa ficar dois anos para trás, não um.

A segunda: o valor de estar em LTS aumenta. Com menos linhas ativas, ficar fora do suporte fica mais visível e mais arriscado.

A terceira: a Temporal API vira baseline mais rápido. Habilitada por padrão no 26, ela deixa de ser experimento e passa a ser a forma esperada de lidar com data e hora — o que, para código brasileiro, significa finalmente tratar fuso e horário de verão sem gambiarra de biblioteca.

E o lembrete de agosto: atualizar não é só cadência

No mesmo mês, o ecossistema recebeu um recado do outro lado. O release de segurança do Next.js de agosto de 2026 corrigiu duas vulnerabilidades de severidade crítica, publicado nas versões 16.3.3 (Active LTS) e 15.5.24 (Maintenance LTS).

Vale a observação porque a discussão sobre cadência de release costuma ser tratada como assunto de arquiteto, e a de patch de segurança como assunto de emergência. São o mesmo assunto: a facilidade de aplicar o patch depende de quão longe você está da versão suportada.

Time que está em LTS atual sobe a correção crítica numa tarde. Time que está três majors atrás descobre, no meio do incidente, que o patch não existe para a versão dele — e que a atualização que ele vinha adiando virou pré-requisito para não ficar exposto.

O que fazer nas próximas semanas

A cadência anual dá uma oportunidade rara de organizar isso de forma definitiva. Vale levantar em quais versões de Node cada serviço da empresa roda hoje — a resposta costuma surpreender —, marcar a data de fim de suporte de cada uma no mesmo calendário em que entram as entregas de produto, e tratar atualização de runtime como item recorrente de roadmap, não como dívida técnica que aparece quando quebra.

Uma major por ano torna esse plano viável pela primeira vez em muito tempo. É menos trabalho de manutenção, desde que alguém decida fazê-lo.