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.
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:
|First – Newest Release
|2008/09/02 – 2022/03/29
|2003/01/07 – 2022/03/13
|2002/09/23 – 2022/03/23
|2013/05/29 – 2022/03/29
|2018/01/09 – 2022/01/08
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!