guides

Wenn Sie ein JavaScript-Projekt pflegen, kommt eine praktische Frage immer wieder auf: Wie oft veröffentlichen die Werkzeuge, von denen Sie abhängen, tatsächlich eine neue Version? Wir haben es gemessen statt geraten. Über die öffentliche GitHub-Releases-API haben wir die letzten 100 Releases von zehn weit verbreiteten Front-End-Projekten abgerufen und echte stabile Releases von Vorabversionen getrennt. Die Spannweite fiel weit größer aus als erwartet, und ein Projekt sticht auf eine Weise heraus, die verändert, wie man seine Versionsnummern lesen sollte.

Die Methode ist bewusst einfach gehalten, damit sie jeder wiederholen kann. Für jedes Repository haben wir die 100 zuletzt veröffentlichten Releases abgefragt, Entwürfe ausgeschlossen und ein Release als Vorabversion markiert, wenn die API es als solche kennzeichnete oder wenn sein Tag alpha, beta, rc, canary, next, experimental, nightly oder ein Suffix -pre enthielt. Die stabile Taktung ist die Anzahl der Tage zwischen dem ältesten und dem neuesten stabilen Release in diesem Fenster, geteilt durch die Anzahl der Intervalle. Jede Zahl unten ist gegen denselben öffentlichen Endpunkt reproduzierbar.

Die Überraschung: Next.js veröffentlicht 88 Prozent Vorabversionen

Das erste Ergebnis ist dasjenige, das uns überrascht hat. Von den letzten 100 Releases, die Next.js veröffentlicht hat, waren nur 12 stabil: 88 Prozent waren Vorabversionen. Das ist kein Zeichen von Instabilität, es ist ein bewusstes Entwicklungsmodell. Next.js veröffentlicht nahezu durchgehend Canary-Builds, und Funktionen landen dort lange, bevor sie in einer stabilen Version erscheinen. Wenn Sie dem Release-Feed des Repositorys folgen und stabile Versionen erwarten, lesen Sie überwiegend Canaries.

Das ist in der Praxis relevant. Ein Projekt, das Canaries als GitHub-Releases veröffentlicht, wirkt enorm viel aktiver als eines, das das nicht tut, selbst wenn beide stabile Versionen in ähnlichem Tempo ausliefern. Eine Abhängigkeit danach zu beurteilen, wie viele Releases vorbeiscrollen, sagt etwas über ihre Veröffentlichungsgewohnheiten aus, nicht über ihre Stabilität oder ihr Tempo echter Änderungen.

Der umgekehrte Ansatz: keine Vorabversionen

Am entgegengesetzten Ende haben zwei Projekte in unserer Stichprobe im Fenster überhaupt keine Vorabversionen auf GitHub veröffentlicht: Svelte und React Router, beide bei null. React und Preact lagen nahe dran, bei 2 und 3 Prozent. Diese Projekte nutzen entweder keine Vorabversionen oder veröffentlichen sie nicht als GitHub-Releases, sodass sich ihr Release-Feed wie eine saubere Liste stabiler Versionen liest.

• Von den letzten 100 Next.js-Releases waren nur 12 stabil: 88 Prozent waren Vorabversionen (Canary-First-Entwicklung).
• Svelte und React Router veröffentlichten im selben Fenster null Vorabversionen auf GitHub; React und Preact lagen bei 2 und 3 Prozent.
• Die stabile Taktung erstreckt sich über rund das Achtzigfache: Astro lag im Mittel bei 0,5 Tagen zwischen stabilen Releases, React bei fast 40.
• Die reine Anzahl der Releases führt in die Irre: Ein Projekt, das Canaries als Releases veröffentlicht, wirkt weit aktiver als eines, das das nicht tut.
• Methode: die letzten 100 veröffentlichten GitHub-Releases pro Repository, Entwürfe ausgeschlossen, Vorabversionen anhand des API-Flags oder des Tags erkannt, erhoben am 2026-07-27.

Zwischen den Extremen liegen die Projekte, die Vorabversionen deutlich, aber nicht ausschließlich nutzen: Vue bei 35 Prozent, Angular bei 32, Astro bei 31 und Vite bei 28. Rund ein Drittel dessen, was sie veröffentlichen, ist eine Vorschau auf etwas noch nicht Fertiges.

Wie oft stabile Versionen wirklich erscheinen

Betrachtet man nur die stabilen Releases, teilen sich die Tage dazwischen in klare Gruppen. Astro lag im Mittel bei 0,5 Tagen, Svelte bei 2,8, Angular bei 3,2 und Vite bei 4,3. Next.js lag bei 7,2 Tagen für stabile Versionen, Nuxt bei 11,9, React Router bei 12,5 und Vue bei 14,2. Preact lag im Mittel bei 19,1 Tagen und React bei 39,7. Jede Zahl ist über das jeweils eigene Fenster des Projekts aus seinen letzten 100 Releases gemessen.

Das Auffälligste ist die Spannweite. Astro veröffentlichte in seinem Fenster alle halben Tage ein stabiles Release, während React im Mittel fast 40 Tage zwischen stabilen Releases lag: ein Unterschied von rund dem Achtzigfachen. Svelte, Angular und Vite gruppieren sich im Bereich von zwei bis vier Tagen, Next.js bei etwa einer Woche für stabile Versionen, und Nuxt, React Router und Vue zwischen zwölf und vierzehn Tagen.

Schnell ist nicht besser als langsam

Es wäre ein Fehler, das langsame Ende als Vernachlässigung zu lesen. Das Fenster von React reicht genau deshalb bis 2016 zurück, weil es wenige, große, gut voneinander getrennte Releases veröffentlicht, und genau das will man von einer grundlegenden Bibliothek, von der Tausende Pakete abhängen. Eine schnelle und eine langsame Taktung sind Antworten auf unterschiedliche Fragen, keine Rangfolge.

Für Maintainer geht es in der praktischen Schlussfolgerung um Erwartungen. Wenn Sie von etwas aus der Gruppe unterhalb einer Woche abhängen, planen Sie häufige, kleine Updates ein und stützen Sie sich auf automatisierte Dependency-Updates und eine Lockfile, denn jedes Release von Hand zu prüfen wird nicht skalieren. Wenn Sie von etwas aus der monatlichen Gruppe abhängen, sind Updates seltener, tragen aber tendenziell mehr Änderungen pro Release, kalkulieren Sie also mehr Zeit für jedes einzelne ein.

Die Grenzen dieser Messung

Die Grenzen dieser Messung sind so wichtig wie die Zahlen, deshalb benennen wir sie klar. Das Fenster sind die letzten 100 Releases, was für jedes Projekt einen anderen Zeitraum abdeckt: etwa zehn Jahre für React, aber nur etwa fünf Wochen für Astro. Das sind Momentaufnahmen des aktuellen Veröffentlichungsverhaltens, keine vergleichbaren historischen Durchschnittswerte. Wir messen nur GitHub-Releases, ein Projekt, das Vorabversionen auf npm veröffentlicht, ohne ein GitHub-Release anzulegen, scheint also keine zu haben. Monorepos, die pro Paket veröffentlichen, können die Release-Zahlen aufblähen. Und alle Zahlen wurden am 2026-07-27 erhoben und werden sich verschieben.

Was Sie mitnehmen sollten

Die nützliche Schlussfolgerung ist nicht, dass ein Projekt besser ist als ein anderes. Sie lautet, dass die reine Anzahl der Releases ein schlechtes Signal ist. Bevor Sie eine Abhängigkeit nach ihrer Aktivität beurteilen, prüfen Sie, welcher Anteil dieser Releases tatsächlich stabil ist und über welchen Zeitraum sie veröffentlicht wurden. In dieser Stichprobe verwandelte das ein scheinbar hyperaktives Projekt in einen normalen wöchentlichen Release-Rhythmus, eingehüllt in durchgehende Canaries.