These replies are incredibly and bizarrely dogmatic. I never knew it'd be so hard to have a discussion about semver without people just going "semver is semver" as if that means something.
You seem to have misunderstood. We're not pointing out that "semver is semver", we're pointing out that semver as defined with respect to compilers, which is to say, the ability of existing code to run with a new version of the compiler, and what you "perceive to be a limitation in semver" are fundamentally in tension.
The only non-perf changes that would be allowed as non-breaking changes if we addressed what you perceive to be limitations in semver are precisely those changes which would be breaking in semver-as-it-exists, and those permitted in semver-as-it-exists are precisely those which you perceive as limitations.
Happy to discuss semver, but fundamentally the thing here is that what would address your perceived limitations is... the literal opposite of semver. Which is fine! But something not being its literal exact opposite isn't exactly a flaw in the thing itself; you simply want something else entirely.
And again, I did not propose "the opposite of semver" or anything else. I said "some changes are poorly described by semver". It's a big leap from that to "I know exactly what you have in mind and it is every change is a major change." Which I... did not say anywhere?
Though, I do think that, as I mentioned elsewhere, this is approximately the net practical effect of using semver for things that have a principled opposition to breaking of backwards compatibility. If you never go to '2.0.0' then the '1.' part of '1.234234.0' is meaningless. Your version is just 234234.0 and you're playing the same game of pretend that '0.x' does in semver only with a bigger number. Again though, this is not me proposing that, it is me observing that the thing you're arguing against is possibly what's really happening anyways.
