SemVer puts the responsibility on the maintainer to assume how users are using the library.
I think by now we've learned that even though SemVer was a good idea, people are people and they are gonna eventually fail at setting the version correctly, making your assumptions broken
Treating every patch release of Django like a major release would be a major waste of time compared to “assume Django maintainers have a good idea of how things are used, and rely on automated test suite”
That sounds either worse. Software releases should be immutable, so no changing existing versions.
And also, if X.Y is incompatible (because they screwed up the versioning, as in your example), X.Z should also be incompatible (according to semver), otherwise you break semver twice instead of just once...
> Treating every patch release of Django like a major release would be a major waste of time
Yeah, I guess computing time. If you manually testing each dependency update, your doing something wrong. This should be automated to such level as you feel comfortable stuff is working by just running the tests.
With SemVer the library maintainer tells you "here, let me help you". With CalVer the maintainer says "fuck that, I'm out". None changes your responsibility.
Semantic versioning lets the user decide.
For an API it seems like a no-brainer to use semantic versioning, makes it easier to document feature deprecation, like supporting latest two major releases and so on.