4 ms·
The simple explanation is that Semantic Versioning is not at all the only way to do versioning, it is just one standard amongst others. Of course semver is prog
by jlundborg 10y ago
The simple explanation is that Semantic Versioning is not at all the only way to do versioning, it is just one standard amongst others. Of course semver is progress in the sense that it has a specification that means you can assign meaning to the versions, but hey, so does the proposed versioning scheme for GTK. It is just not semver.
I think it is interesting to think about what the versioning scheme says about the development model and methodology of the project:
Linux currently uses even-odd versioning, but regardless tries to never break APIs or ABIs
https://en.wikipedia.org/wiki/Linux_kernel#Version_numbering https://en.wikipedia.org/wiki/Linux_kernel#Version_numbering
After much debate, Linux switched from a model where the major number never changed, which is kinda inline with semver. But since this seemed increasingly silly, to have a 3 there forever, they decided to just throw this overboard and start incrementing the version number more often. (This discussion was much more interesting in reality, read LKML for details).
Android uses an interesting brand-version and actually-useful-version scheme (API level)
https://en.wikipedia.org/wiki/Android_version_history https://en.wikipedia.org/wiki/Android_version_history
This very much reflects how versioning and releasing a new version has become a PR event. It is really funny how this distinction is even reflected in code.
And then of course there are the funky oddballs:
https://en.wikipedia.org/wiki/TeX https://en.wikipedia.org/wiki/TeX
This asymptotically more precise number is suitable for a project that has the idea that it is approaching perfection without changing much. Not sure if every TeX user out there would agree, but it indeed says something about the author =).
There are plenty others, and of course it can be confusing if you think that semver is the only game in town. Perhaps the ideas expressed in the semver spec simple does not suit everyone.
- BinaryIdiot 10y ago> The simple explanation is that Semantic Versioning is not at all the only way to do versioning, it is just one standard amongst others.[...]it can be confusing if you think that semver is the only game in town I certainly don't think semver is the only game in town but the vast majority of versioning techniques out there are very, very similar to semver where major updates are the only ones that can affect the API. I wouldn't expect semver to suit everyone (honestly I prefer a slightly different version that was more common in the .Net universe) but at the same time most versioning techniques behave similarly. The Gtk way is fine if it works for them but it certainly isn't common. Versioning is one of the very few things that I would be willing to give up what I think is ideal to settle for something most commonly used (why I use semver when working in JavaScript). I'm not sure what the most common versioning scheme there is but at least anecdotally it seems fairly similar to semver or at least a subset of semver.