SemVer remains a pragmatic approach that works in vast amount of cases. It’s unclear what alternative we have here which works in more cases.
We don't have any better alternative, but lets not be naive about it when it comes to building bits of framework.
Semver would just be an artificial impediment at this level.
SemVer is an impediment only if you insist to make it so.
Go takes an alternative approach:
That's not a new idea, I also put the version in my package name, so that you can use v1.x with v2.x etc.
It doesn't contradict SemVer.
However when you do that, it becomes a big deal to jump from one version to another even if the breaks are minor. So pros and cons.
Re:Unison Programming Language
by uncomputation on Monday June 28, 2021 @03:43AM
(#27659083)
(Mentioned xkcd: https://xkcd.com/1172/)
You can scream at the developers that they've violated semver but a "bugfix" is entirely subjective (relevant xkcd, spacebar heating, etc).
And even when developers violate semver in a point release the problem still exists. They actually rarely, if ever, rollback with a 1.0.2 that is equivalent to 1.0.0 and instead usually move forwards.
And if you have a language that supports loading 1.0 and 1.1 then there's no point in being artificially constrained over which two versions can be loaded at the same time based on the label, the underlying framework shouldn't be built to care. There's no need for a multi-version library loader to care about what a bugfix is.