It shows that semantic versioning is a bad idea 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!).
> > > On Fri, Nov 19, 2021 at 9:51 PM Anton Vodonosov <avodono...@yandex.ru> wrote: >> - etimmons@, rpgoldman@ >> >> "Erik Huelsmann" <ehu...@gmail.com>: >> > Could you elaborate a bit on "As semver does not work for Common Lisp"? >> >> I've opened an issue in the SemVer github repo: >> https://github.com/semver/semver/issues/771 >> (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. > > http://efficito.com -- Hosted accounting and ERP. > Robust and Flexible. No vendor lock-in. -- Stelian Ionescu
