4 ms·
How about the following scenario: Package A is SemVer 1.2.3, package B is PragVer 1.2.3. both A and B have big release with breaking changes and marketing hype
by nosefurhairdo 3y ago
How about the following scenario:
Package A is SemVer 1.2.3, package B is PragVer 1.2.3. both A and B have big release with breaking changes and marketing hype, so now they're both at 2.0.0. It is later found that in version 1 of both packages there is a bug requiring a breaking change in order to fix. B (pragmatic) can apply the fix to version 1 branch and release it as 1.3.0. How does A (semantic) make a breaking change on version 1 and version it correctly?
TL;DR Pragmatic Versioning enables breaking changes on LTS versions.
- ori_b 3y agoThe point of LTS versions is that they don't force me to make changes. This sounds like a bug more than a feature.
- nosefurhairdo 3y agoNot all breaking changes require consumers to make changes. For example, in react-router v6, the useSearchParams hook returns a setter which lacks referential stability (for no good reason). There is an open PR to fix this, but the maintainers haven't addressed it. My theory is that it would technically be a breaking change since it would cause fewer rerenders. Theoretically an app might rely on this, but in practice that would be an extremely brittle and unusual behavior to rely on, and the vast majority of users would prefer the reduced rerenders. Under pragmatic versioning they could bump v6.x, and note that the change should be tested but likely doesn't require any code changes. With SemVer they'd be forced to bump to 7.0.0, but this is not a marketable change for a major release.
- matijsvzuijlen 3y agoIf you follow SemVer strictly, the version bump is not necessary unless the number of rerenders is part of the documented API.