I think you have the cart and horse the wrong way around. SemVer doesn't say that it's okay to break compatibility in major version updates, it defines "major v

I think you have the cart and horse the wrong way around. SemVer doesn't say that it's okay to break compatibility in major version updates, it defines "major version update" to mean "any update which breaks compatibility". If a piece of software hasn't broken compatibility but still wants to tell people they've passed a big feature milestone, it's perfectly reasonable (and I think explicitly encouraged) to have separate user-facing and semantic versions - so you tell people it's "Foo 2.0" but publish it to npm as foo@1.37.0. This is right and proper because the semver number exists solely to describe whether an update adds features and breaks compatibility or not; anyone using it otherwise is misusing semver.