guides

Se mantieni un progetto JavaScript, una domanda pratica torna di continuo: con quale frequenza gli strumenti da cui dipendi rilasciano davvero una nuova versione? L'abbiamo misurata invece di indovinarla. Usando l'API pubblica GitHub Releases, abbiamo estratto le ultime 100 release di dieci progetti front-end molto diffusi e separato le vere release stabili dalle prerelease. La dispersione si è rivelata molto più ampia del previsto, e un progetto spicca in un modo che cambia il modo in cui vanno letti i suoi numeri di versione.

Il metodo è volutamente semplice, così che chiunque possa ripeterlo. Per ogni repository abbiamo richiesto le 100 release pubblicate più recenti, escluso le bozze e contrassegnato una release come prerelease se l'API la segnalava come tale o se il suo tag conteneva alpha, beta, rc, canary, next, experimental, nightly o un suffisso -pre. La cadenza stabile è il numero di giorni tra la release stabile più vecchia e la più recente in quella finestra, diviso per il numero di intervalli. Ogni cifra qui sotto è riproducibile sullo stesso endpoint pubblico.

La sorpresa: Next.js pubblica l'88 per cento di prerelease

Il primo risultato è quello che ci ha sorpreso. Delle ultime 100 release pubblicate da Next.js, solo 12 erano stabili: l'88 per cento erano prerelease. Non è un segno di instabilità, è un modello di sviluppo deliberato. Next.js pubblica build canary quasi in continuazione, e le funzionalità arrivano lì molto prima di comparire in una versione stabile. Se segui il feed delle release del repository aspettandoti versioni stabili, starai leggendo soprattutto canary.

Questo conta nella pratica. Un progetto che pubblica le canary come release GitHub sembrerà enormemente più attivo di uno che non lo fa, anche se entrambi rilasciano versioni stabili a un ritmo simile. Giudicare una dipendenza da quante release scorrono ti dice qualcosa sulle sue abitudini di pubblicazione, non sulla sua stabilità né sulla sua velocità di cambiamento reale.

L'approccio opposto: nessuna prerelease

All'estremo opposto, due progetti del nostro campione non hanno pubblicato alcuna prerelease su GitHub durante la finestra: Svelte e React Router, entrambi a zero. React e Preact erano vicini, al 2 e al 3 per cento. Questi progetti o non usano prerelease o non le pubblicano come release GitHub, quindi il loro feed di release si legge come un elenco pulito di versioni stabili.

• Delle ultime 100 release di Next.js, solo 12 erano stabili: l'88 per cento erano prerelease (sviluppo canary-first).
• Svelte e React Router hanno pubblicato zero prerelease su GitHub nella stessa finestra; React e Preact erano al 2 e al 3 per cento.
• La cadenza stabile si estende su circa ottanta volte: Astro ha registrato una media di 0,5 giorni tra release stabili, React quasi 40.
• Il solo conteggio delle release trae in inganno: un progetto che pubblica le canary come release sembra molto più attivo di uno che non lo fa.
• Metodo: le ultime 100 release GitHub pubblicate per repository, bozze escluse, prerelease identificate dal flag dell'API o dal tag, raccolti il 2026-07-27.

Tra gli estremi si collocano i progetti che usano le prerelease in modo sostanziale ma non esclusivo: Vue al 35 per cento, Angular al 32, Astro al 31 e Vite al 28. Circa un terzo di ciò che pubblicano è un'anteprima di qualcosa non ancora finito.

Con quale frequenza escono davvero le versioni stabili

Guardando solo alle release stabili, i giorni che le separano si dividono in gruppi netti. Astro ha registrato una media di 0,5 giorni, Svelte 2,8, Angular 3,2 e Vite 4,3. Next.js si è attestato a 7,2 giorni per le versioni stabili, Nuxt a 11,9, React Router a 12,5 e Vue a 14,2. Preact ha registrato una media di 19,1 giorni, e React 39,7. Ogni cifra è misurata sulla finestra propria di ciascun progetto, quella delle sue ultime 100 release.

Il dato principale è la dispersione. Astro ha pubblicato una release stabile ogni mezza giornata nella sua finestra, mentre React ha registrato una media di quasi 40 giorni tra release stabili: una differenza di circa ottanta volte. Svelte, Angular e Vite si raggruppano nell'intervallo da due a quattro giorni, Next.js intorno a una settimana per le versioni stabili, e Nuxt, React Router e Vue tra dodici e quattordici giorni.

Veloce non significa meglio di lento

Sarebbe un errore leggere l'estremo lento come trascuratezza. La finestra di React risale al 2016 proprio perché pubblica poche release, grandi e ben distanziate, che è esattamente ciò che si vuole da una libreria fondamentale da cui dipendono migliaia di pacchetti. Una cadenza veloce e una cadenza lenta sono risposte a domande diverse, non una classifica.

Per chi mantiene un progetto, la conclusione pratica riguarda le aspettative. Se dipendi da qualcosa del gruppo sotto la settimana, mettiti in conto aggiornamenti frequenti e piccoli, e affidati ad aggiornamenti automatici delle dipendenze e a un lockfile, perché rivedere ogni release a mano non sarà sostenibile. Se dipendi da qualcosa del gruppo mensile, gli aggiornamenti sono più rari ma tendono a portare più cambiamenti per release, quindi metti in preventivo più tempo per ciascuno.

I limiti di questa misurazione

I limiti di questa misurazione contano quanto i numeri, quindi li dichiariamo apertamente. La finestra è quella delle ultime 100 release, che copre un periodo diverso per ogni progetto: circa dieci anni per React ma solo circa cinque settimane per Astro. Sono istantanee del comportamento di pubblicazione attuale, non medie storiche confrontabili. Misuriamo solo le release GitHub, quindi un progetto che pubblica prerelease su npm senza creare una release GitHub risulterà non averne alcuna. I monorepo che pubblicano per pacchetto possono gonfiare il conteggio delle release. E tutte le cifre sono state raccolte il 2026-07-27 e cambieranno nel tempo.

Che cosa ricordare

La conclusione utile non è che un progetto sia migliore di un altro. È che il solo conteggio delle release è un segnale scadente. Prima di giudicare una dipendenza dalla sua attività, controlla quale quota di quelle release è davvero stabile, e in quale periodo sono state pubblicate. In questo campione, farlo ha trasformato un progetto apparentemente iperattivo in un normale calendario di rilascio settimanale avvolto in canary continue.