Com que frequência os frameworks JavaScript lançam realmente? Medimos 1000 versões

  • VersionDude
  • guides
  • 8 min de leitura

Recolhemos as últimas 100 versões do GitHub de dez projetos front-end e separámos as versões estáveis das pré-versões. O Next.js revelou-se com 88 por cento de pré-versões, o Svelte e o React Router com zero, e a cadência estável abrange um fator de cerca de oitenta vezes. Dados, método e limites.

Se mantens um projeto JavaScript, há uma pergunta prática que volta sempre: com que frequência é que as ferramentas de que dependes lançam realmente uma nova versão? Medimo-la em vez de a adivinhar. Usando a API pública GitHub Releases, recolhemos as últimas 100 versões de dez projetos front-end muito usados e separámos as versões estáveis reais das pré-versões. A dispersão revelou-se muito maior do que o esperado, e um projeto destaca-se de uma forma que muda o modo como devemos ler os seus números de versão.

O método é deliberadamente simples para que qualquer pessoa o possa repetir. Para cada repositório pedimos as 100 versões publicadas mais recentes, excluímos os rascunhos e marcámos uma versão como pré-versão se a API a assinalasse como tal ou se a sua tag contivesse alpha, beta, rc, canary, next, experimental, nightly ou um sufixo -pre. A cadência estável é o número de dias entre a versão estável mais antiga e a mais recente dessa janela, dividido pelo número de intervalos. Todos os valores abaixo são reproduzíveis contra o mesmo endpoint público.

A surpresa: o Next.js publica 88 por cento de pré-lançamentos

Uma agenda de papel com encadernação em espiral aberta em meados de abril e uma caneta pousada sobre a página. A cadência de lançamento resume-se à frequência com que essas datas se preenchem.
Uma agenda de papel com encadernação em espiral aberta em meados de abril e uma caneta pousada sobre a página. A cadência de lançamento resume-se à frequência com que essas datas se preenchem.

O primeiro resultado é o que nos surpreendeu. Das últimas 100 versões publicadas pelo Next.js, apenas 12 eram estáveis: 88 por cento eram pré-versões. Isso não é sinal de instabilidade, é um modelo de desenvolvimento deliberado. O Next.js publica builds canary de forma quase contínua, e as funcionalidades chegam lá muito antes de aparecerem numa versão estável. Se seguires o feed de versões do repositório à espera de versões estáveis, estarás a ler sobretudo canaries.

Isto importa na prática. Um projeto que publica canaries como versões do GitHub vai parecer enormemente mais ativo do que um que não o faz, mesmo que ambos lancem versões estáveis a um ritmo semelhante. Julgar uma dependência pelo número de versões que passam diz-te algo sobre os seus hábitos de publicação, não sobre a sua estabilidade nem sobre a sua velocidade de mudança real.

A abordagem oposta: zero pré-lançamentos

No extremo oposto, dois projetos da nossa amostra não publicaram qualquer pré-versão no GitHub durante a janela: Svelte e React Router, ambos a zero. React e Preact ficaram perto, com 2 e 3 por cento. Estes projetos ou não usam pré-versões ou não as publicam como versões do GitHub, pelo que o seu feed de versões se lê como uma lista limpa de versões estáveis.

  • Das últimas 100 versões do Next.js, apenas 12 eram estáveis: 88 por cento eram pré-versões (desenvolvimento canary-first).
  • Svelte e React Router publicaram zero pré-versões no GitHub na mesma janela; React e Preact estavam nos 2 e 3 por cento.
  • A cadência estável abrange cerca de oitenta vezes: o Astro registou uma média de 0,5 dias entre versões estáveis, o React quase 40.
  • A contagem de versões, por si só, induz em erro: um projeto que publica canaries como versões parece muito mais ativo do que um que não o faz.
  • Método: as últimas 100 versões publicadas no GitHub por repositório, rascunhos excluídos, pré-versões identificadas pelo indicador da API ou pela tag, recolhido a 2026-07-27.

Entre os extremos estão os projetos que usam pré-versões de forma substancial mas não exclusiva: Vue com 35 por cento, Angular com 32, Astro com 31 e Vite com 28. Cerca de um terço do que publicam é uma antevisão de algo que ainda não está terminado.

Com que frequência saem realmente as versões estáveis

Olhando apenas para as versões estáveis, os dias entre elas dividem-se em grupos nítidos. O Astro registou uma média de 0,5 dias, o Svelte 2,8, o Angular 3,2 e o Vite 4,3. O Next.js ficou nos 7,2 dias para as versões estáveis, o Nuxt nos 11,9, o React Router nos 12,5 e o Vue nos 14,2. O Preact registou uma média de 19,1 dias, e o React 39,7. Cada valor é medido sobre a janela própria de cada projeto, a das suas últimas 100 versões.

O ponto principal é a dispersão. O Astro publicou uma versão estável a cada meio dia na sua janela, enquanto o React registou uma média de quase 40 dias entre versões estáveis: uma diferença de cerca de oitenta vezes. Svelte, Angular e Vite agrupam-se no intervalo de dois a quatro dias, o Next.js à volta de uma semana para as versões estáveis, e Nuxt, React Router e Vue entre doze e catorze dias.

Rápido não é melhor do que lento

Seria um erro ler o extremo lento como negligência. A janela do React recua até 2016 precisamente porque publica poucas versões, grandes e bem espaçadas, que é exatamente o que se quer de uma biblioteca fundacional da qual dependem milhares de pacotes. Uma cadência rápida e uma cadência lenta são respostas a perguntas diferentes, não uma classificação.

Para quem mantém um projeto, a conclusão prática tem a ver com expectativas. Se dependes de algo do grupo abaixo da semana, conta com atualizações frequentes e pequenas, e apoia-te em atualizações automatizadas de dependências e num lockfile, porque rever cada versão à mão não vai escalar. Se dependes de algo do grupo mensal, as atualizações são mais raras mas tendem a trazer mais mudanças por versão, portanto reserva mais tempo para cada uma.

Os limites desta medição

Os limites desta medição importam tanto como os números, por isso enunciamo-los com clareza. A janela são as últimas 100 versões, o que cobre um período diferente para cada projeto: cerca de dez anos para o React mas apenas cerca de cinco semanas para o Astro. São instantâneos do comportamento de publicação atual, não médias históricas comparáveis. Medimos apenas as versões do GitHub, por isso um projeto que publique pré-versões no npm sem criar uma versão do GitHub parecerá não ter nenhuma. Os monorepos que publicam por pacote podem inflacionar a contagem de versões. E todos os valores foram recolhidos a 2026-07-27 e vão mudar.

Os limites desta medição importam tanto como os números, por isso enunciamo-los com clareza. A janela são as últimas 100 versões, o que cobre um período diferente para cada projeto: cerca de dez anos para o React mas apenas cerca de cinco semanas para o Astro. São instantâneos do comportamento de publicação atual, não médias históricas comparáveis. Medimos apenas as versões do GitHub, por isso um projeto que publique pré-versões no npm sem criar uma versão do GitHub parecerá não ter nenhuma. Os monorepos que publicam por pacote podem inflacionar a contagem de versões. E todos os valores foram recolhidos a 2026-07-27 e vão mudar.

- VersionDude

O que reter

A conclusão útil não é que um projeto seja melhor do que outro. É que a contagem de versões, por si só, é um mau sinal. Antes de julgares uma dependência pela sua atividade, verifica que proporção dessas versões é realmente estável, e ao longo de que período foram publicadas. Nesta amostra, fazê-lo transformou um projeto aparentemente hiperativo num calendário de lançamento semanal normal envolto em canaries contínuos.

Projeto relacionado