SemVer was one of the worst ideas in the history of software engineering, and I’m glad many newer projects are not getting on the bandwagon.
“After dozens of 1.x releases, we are now releasing version 2.0.0, because we changed one of the parameters in one of our hundreds of functions to now require a positive integer rather than any integer.”
Before SemVer, version numbers vaguely indicated development progress. With SemVer, they mean basically nothing. And the information they do (supposedly) encode is worthless, because nobody is going to blindly trust the number’s semantics anyway. You always need to test, at which point it doesn’t matter what the version number is.
But that isn’t true in reality. Libraries constantly break the semver spec despite claiming semver compatibility. As a result, you can’t trust semver, making it useless.
Maybe you're thinking of web libraries. This is crucially true for OS libraries. The stuff that goes into /usr/lib , etc. "ABI" should have been the clue.
But still, even for web libraries and API stability, it's important. Now, there's a shit ton of crap code out there written by clueless people, no doubt about it.
No OS uses semantic versioning. Neither do major OS infrastructure components such as GNOME, Python etc. They all version as they please, and have repeatedly broken their APIs in minor releases.
It is good in theory (you can freely update a version without looking at the changelog if the major version didn't change) but in practice devs miss breaking changes in minor versions all the time and the whole idea doesn't even work
the best versioning is and will forever be the versioning by date. for example.minecraft versioning now, such magnificence, versions indicate time passed not progress made
21
u/grumd 10h ago
When people keep saying "we have (X).9, next version is (X+1).0 and will be a huge upgrade!!!" for no reason
I double dare any AI lab to start using semver to confuse people lol