4 ms·
The only change that isn't "breaking" is one that only adds functionality. Otherwise, it changes behavour, and has the potential to break your software. In pr
by yen223 3y ago
The only change that isn't "breaking" is one that only adds functionality.
Otherwise, it changes behavour, and has the potential to break your software.
In practice, almost all changes should be major version bumps.
Anyway that's besides the point. Let me control when version changes happen!
- treflop 3y agoI used to maintain some open source libraries and absolutely no change we would release would break anything and definitely not over a minor version. We even did a major rewrite that completely changed the API and we broke nothing, but it did mean your project got a lot of deprecation errors. And our docs would mention both the old and new way so if you were searching the Internet for help, you wouldn't get confused when you saw wildly completely examples. It's all about craftmanship.
- brazzy 3y ago>The only change that isn't "breaking" is one that only adds functionality. Ha! Think again. On of the more annoying problems I had to analyze was when a new PHP version added a function that already existed in my application (this was before namespaces). The runtime did not like that.
- rezonant 3y agoPatch or major is always a judgement call. Making all changes a major jump is a bad idea, because it means that dependent packages are less likely to adopt important functionality or security fixes. NPM already gives you a way to control when version changes happen, it's called package-lock.json, and it's used for all NPM installs (both in development and when deploying). Just don't listen to the bootcampers on StackOverflow telling you to delete it whenever anything looks weird. If you delete package-lock.json, assume every dependency version has changed and regress accordingly. The same is true of all reasonable version-locking package managers.