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.
> 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.