Semver is a bandaid on a gaping chest wound, that can best be summed up as "major version number changes may break everything, or they may not, but minor version numbers might not break everything, but they may."
It's more of a philosophy than a law, and it can't really be relied on that much; as often the developers themselves can't accurately predict what is a major breaking change and what isn't.
The Linux kernel itself has some baggage from the 2.4/2.6 era that Linus is explicitly walking away from.
Actually testing is the bandaid .
You always have the dilemma when updating dependencies of the software - do they break something? Of course you could manually check every time every software from changelog, if this has some impact.
Problem is, that usually for example in Linux one dependency might have hundreds of dependents. Are you going to check all of them manually?
If standard versioning would automatically show this information, a lot of time and testing would be saved.
> often the developers themselves can't accurately predict what is a major breaking change and what isn't.
There is a difference with a breaking change and a bug.
All breaking changes are predictable. If you modify API, it possible breaks. If you don’t modify API but it breaks, it is just a bug.
If you add feature, and don’ t modify API, but something breaks, it is a bug.
You are not expected to apply SemVer for bugs because you can’t predict them.
They can read the changelog. And if they can't be bothered to read the changelog, then why even update?