5 ms·
I thought upgrading from 2.x.x to 4.x.x shold break something according to SemVer. So why "it's backwards compatible with 2.x.x"?
by batat 10y ago
I thought upgrading from 2.x.x to 4.x.x shold break something according to SemVer. So why "it's backwards compatible with 2.x.x"?
- a-kojeve 10y agoI think the distinction is that a breaking API change breaks some of your code, a backward incompatible change breaks your entire codebase -- i.e., fix a few method signatures vs refactor your entire codebase.
- tomku 10y agoYou've got it backwards. If you make a breaking change, semver requires you to bump the version number. There is absolutely nothing in the semver spec requiring you to make a breaking change when you bump the version number. The spec only specifies one of those directions, you're free to bump the major version for any change if you feel like it. Doing so would make your versioning scheme much less useful, but it's not actually breaking the semver rules.
- WorldMaker 10y agoThere's also nothing in the spec that stops you from taking a very conservative view of what constitutes a "breaking change". There are many types of changes that may be backwards compatible and you're mostly sure shouldn't break anything, but you want to signal that it might just in case. What constitutes a breaking change that warrants a major version bump is a subjective problem left to project maintainers.
- tomku 10y agoTotally agree, and I think that's what's going on with Angular. Bumping the major version for a set of modules also communicates that you really should be using 4.x of all these modules together rather than mixing and matching with 2.x, even if some subset of them are technically backwards compatible.