4 ms·
Why, I'm so glad you asked. In short — true compatibility determined by the test suite, which tells you exactly how compatible two pieces of interdependent sof
by jashkenas 12y ago
Why, I'm so glad you asked.
In short — true compatibility determined by the test suite, which tells you exactly how compatible two pieces of interdependent software are. We can automate this.
In long:
Compatibility between any two pieces of software — say an app, and its major dependency — is a rich, yet quantifiable thing. It consists of all of the functions you call (or the classes you use) in the dependency, and the way in which you use them. These uses should be covered by tests.
If a library with a large surface area of 100 functions releases a new version ... and that version changes 1 of the lesser-used functions to have different behavior for an edge case, then by SemVer's fiat, it's a Breaking Change, and you bump the version number, and 99.89% of the library users that won't see any trouble in their application won't get the "free" upgrade. That's silly.
In a sanely written library, general backwards-compatibility is always a priority, and it's entirely possible and likely that a well-written app will be able to upgrade without any problems through dozens of "breaking" major revisions. At that point, the "Semantic" version is just a false flag that would be better off ignored. That's silly.
We have robust test suites that tell us exactly what goes wrong, and how, and where. We just need a tool that provisionally upgrades your dependencies (without regard to version) — runs your tests, and tells you what works, and what needs to be updated. If all is well, all is well. The tool can (safely! with assurances!) write the new version in your package.json (or what have you), and you can go merrily on your way. If a test fails, you update your code, or the tool can write into your package.json exactly the version ranges your current code is compatible with.
Why would you ever let a third party — no matter how well intentioned — remotely break your app?
Versions can go back to being for people, not for robots.
- jrochkind1 12y ago> and that version changes 1 of the lesser-used functions to have different behavior for an edge case, then by SemVer's fiat, it's a Breaking Change IF that function was part of the "public API". (AND the previous behavior was not a bug? You can fix bugs without major version bump in semver) This is the trickiest part of semver in actual practice, in my experience, having a clear definition and shared understanding between producers and consumers of what the 'public API' is. I agree tests is the operationalized way to know if 'something has changed in a backwards compat' way; I've considered somehow tagging certain tests as 'public api' and others as not (or vice versa, public api by default unless tagged private). And then perhaps there's a rule, you can not change any test marked public API unless it's going to be a major version bump (or unless the test itself was buggy I guess? there's always exceptions sadly). And incorporating this info into docs and/or CI somehow. And yeah, actually sticking to semver is not cost-free, for producers or consumers. Everything is a trade off.
- Touche 12y agoYou should write a package manager which does this and publish there instead of NPM. Breaking people's code who use NPM and don't follow your manifesto is wrong.