guides

If you maintain a JavaScript project, one practical question keeps coming back: how often will the tools you depend on actually ship a new version? We measured it rather than guessed. Using the public GitHub Releases API, we pulled the last 100 releases of ten widely used front-end projects and separated genuine stable releases from prereleases. The spread turned out to be far wider than expected, and one project stands out in a way that changes how you should read its version numbers.

The method is deliberately simple so anyone can repeat it. For each repository we requested the 100 most recent published releases, excluded drafts, and marked a release as a prerelease if the API flagged it as one or if its tag contained alpha, beta, rc, canary, next, experimental, nightly or a -pre suffix. Stable cadence is the number of days between the oldest and newest stable release in that window, divided by the number of intervals. Every figure below is reproducible against the same public endpoint.

The surprise: Next.js publishes 88 percent prereleases

The first result is the one that surprised us. Of the last 100 releases published by Next.js, only 12 were stable: 88 percent were prereleases. That is not a sign of instability, it is a deliberate development model. Next.js ships canary builds almost continuously, and features land there long before they appear in a stable version. If you follow the repository's release feed expecting stable versions, you will be reading mostly canaries.

This matters in practice. A project that publishes canaries as GitHub releases will look enormously more active than one that does not, even if both ship stable versions at a similar pace. Judging a dependency by how many releases scroll past tells you about its publishing habits, not its stability or its speed of real change.

The opposite approach: zero prereleases

At the opposite end, two projects in our sample published no prereleases at all on GitHub during the window: Svelte and React Router, both at zero. React and Preact were close, at 2 and 3 percent. These projects either do not use prereleases or do not publish them as GitHub releases, so their release feed reads as a clean list of stable versions.

• Of the last 100 Next.js releases, only 12 were stable: 88 percent were prereleases (canary-first development).
• Svelte and React Router published zero prereleases on GitHub in the same window; React and Preact were at 2 and 3 percent.
• Stable cadence spans about eighty times: Astro averaged 0.5 days between stable releases, React nearly 40.
• Release counts alone mislead: a project publishing canaries as releases looks far more active than one that does not.
• Method: last 100 published GitHub releases per repository, drafts excluded, prereleases identified by API flag or tag, collected 2026-07-27.

Between the extremes sit the projects that use prereleases substantially but not exclusively: Vue at 35 percent, Angular at 32, Astro at 31 and Vite at 28. Roughly a third of what they publish is a preview of something not yet finished.

How often stable versions actually ship

Turning to stable releases only, the days between them break into clear groups. Astro averaged 0.5 days, Svelte 2.8, Angular 3.2 and Vite 4.3. Next.js sat at 7.2 days for stable versions, Nuxt at 11.9, React Router at 12.5 and Vue at 14.2. Preact averaged 19.1 days, and React 39.7. Each figure is measured over that project's own window of its last 100 releases.

The headline is the spread. Astro published a stable release every half day in its window, while React averaged nearly 40 days between stable releases: a difference of roughly eighty times. Svelte, Angular and Vite cluster in the two to four day range, Next.js at about a week for stable versions, and Nuxt, React Router and Vue between twelve and fourteen days.

Fast is not better than slow

It would be a mistake to read the slow end as neglect. React's window stretches back to 2016 precisely because it publishes few, large, well-separated releases, which is exactly what you want from a foundational library that thousands of packages depend on. A fast cadence and a slow cadence are answers to different questions, not a ranking.

For a maintainer, the practical takeaway is about expectations. If you depend on something in the sub-week group, plan for frequent, small updates and lean on automated dependency updates and a lockfile, because reviewing each release by hand will not scale. If you depend on something in the monthly group, updates are rarer but tend to carry more change per release, so budget more time for each one.

The limits of this measurement

The limits of this measurement matter as much as the numbers, so we state them plainly. The window is the last 100 releases, which covers a different period for every project: about ten years for React but only about five weeks for Astro. These are snapshots of current publishing behaviour, not comparable historical averages. We measure GitHub Releases only, so a project publishing prereleases to npm without creating a GitHub release will appear to have none. Monorepos that publish per package can inflate release counts. And all figures were collected on 2026-07-27 and will drift.

What to take away

The useful conclusion is not that one project is better than another. It is that release counts alone are a poor signal. Before you judge a dependency by its activity, check what share of those releases are actually stable, and over what period they were published. In this sample, doing that turned an apparently hyperactive project into a normal weekly release schedule wrapped in continuous canaries.