9 ms·
I said it in the first line: it encourages and legitimises breaking changes. You could argue that all it does is provide a framework for managing versioning in
by bartread 9y ago
I said it in the first line: it encourages and legitimises breaking changes. You could argue that all it does is provide a framework for managing versioning in the presence of breaking changes but that isn't what I see.
- fenomas 9y agoI 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.