It shows that semantic versioning is a bad idea
It's not a bad idea. It's badly executed. If humanity would be forbidden to start executing any good ideas because they will be executed badly, we wouldn't be doing anything today.
If a library says they adhere to semver and they make a mistake, that's a bug as much as a coding mistake is a bug. We have means to point this out to the authors, such as bug trackers. But: the fact that an author releases a version x.y.z doesn't by itself mean they adhere to semver. so maybe the author never intended you to assign this meaning to the version number...
Maybe we need a way for a system declaration to indicate whether its version adheres to semver or not?
Regards,
Erik.
unless you have automatic ways of diffing an API between two versions (such tools exist for C), or the development team has the time and resources to very carefully evolve the code.
What one finds in practice is that authors will wing it and increment version numbers if it "feels" like a major change or for publicity reasons (new major release, get it while it's hot!).
- etimmons@, rpgoldman@
> Could you elaborate a bit on "As semver does not work for Common Lisp"?
(Don't want to repeat this explanation over and over in many discussions).
"One bad programmer can break more than 10 good ones can fix": the issue you raise is bad engineering (increasing the version number simply because you can) and is not a problem semantic versioning is trying to solve. What it *does* try to solve is that the engineers working on the software can see the problems coming. Applications (and libraries) like Subversion have managed to stay within the boundaries of semantic versioning for almost 20 years now, still "stuck" at version 1.x because of it. At the same time they have succeeded to add significant new features to the software without breaking backward compatibility. So: it's possible. The fact that projects like e.g. Cucumber release a new major version every few months says more about those projects than about semver.
I will probably refine the issue description in the future, but it should be clear enough already.
Regards,
--
Bye,
Erik.
Robust and Flexible. No vendor lock-in.