Comment by saghm
21 hours ago
> The entire purpose of semver is to give you a way to resolve that conundrum. New major version = assume it's incompatible.
I'm not sure I'd agree with that characterization. The point of semver is that you can assume that certain types of bumps won't include certain types of changes, not that you assume that the types of changes that can happen in a type of bump will happen. A major version bump not breaking anything is completely valid semver, and breaking one function (which plenty of users might not use, or might use in a way that doesn't get broken) in an API with thousands is still technically only valid in a major version bump (outside of specific exceptions like the major version being 0).
It's a subtle difference, and I'm optimistic that it's something you understand, but misunderstandings of semver seem so common that I can't help but feel like precision when discussing it is important. I've encountered so many smart people who misunderstand aspects of semver (and not just minutia like "what constraints are there on tags after the version numbers"), and almost all of them seemed to have stemmed from people learning a few of basic tenets of it and inferring how to fill in the large gaps in a way that isn't at all how its specified. The semver specification is pretty clear in my opinion even about where some of the edge cases someone less informed might assume, and if we don't agree on that as the definition, I don't know how we avoid the (completely realistic) scenario where everyone in the room has an idea of what "semver" means that's maybe 80% compatible with the spec, but the 80% is different for each of them, and trying to resolve disagreements when people don't agree about what words mean is really hard.
> not that you assume that the types of changes that can happen in a type of bump will happen
… an assumption that something happened is not a definitive statement that it did happen, only that we're assuming it did, because it could happen, or perhaps here, that because the major was bumped, that it is legal, according to the contract given, for it to have possibly happened in a way that we depended on. They're not saying that it will/must; "assume a major version is incompatible" is not at odds with what you've written.
You and I have a very different version of what the equals sign means. "This is a reasonable action to take in this scenario" is not what I understand as equivalence.
Perhaps I should have used an implication sign -> instead of an equals.
Semver says “major version MUST be incremented if any backward incompatible changes are introduced to the public API.” You’re correct that it doesn’t say “major version MUST NOT be incremented if there are no backward incompatible changes”, so technically that is possible — but it would be a very odd thing to do.