Semverflation: a new software metric proposal

Look, y’all—it is well known that I will not shy from posting a ridiculous tweet. And just as a broken clock is right twice a day, sometimes I post a tweet that arguably deserves escalation from the ephermality of the twitterverse to the slightly more hardened blogoverse… blogverse… okay neither of those terms are good—I digress.

Chrome is now at version 100. React just released version 18. It has me thinking that it might be useful to have a standard metric for software that communicates how fast major versions are released.

Introducing: Semverflation.

How do you calculate a software package’s semverflation?

For simplicity, the wild west of pre-1.0 releases are counted when calculating the date of the first release.

Here’s a smattering of semverflation calculations:

What does it mean?

Semverflation takes no position on how well maintained a software package is. A very well maintained package might deliver 100 minor versions and no new major versions (very low semverflation).

A high number is only a measure of the frequency of breaking changes (if the software package adhers to semver). It does not (and can not) measure the volume of breaking changes of a specific major version release.

A low number indicates a measure of stability for the package.

The other thing I like about this metric is that it doesn’t matter how much time has passed between now and the latest release. The semverflation for a retired package will not change over time, if no new releases are being delivered. The semverflation only changes when a new major version is released.

Of course, it’s a little bit wrong to use this metric on web browser releases, who rarely break the web by issuing breaking changes to the platform. But useful for other software packages!