3 ms·
I'm not the author, but I think this idea, as well as Jeremy Ashkenas' reaction to SemVer, both try to address the underlying assumption that all you need is a
by reedlaw 12y ago
I'm not the author, but I think this idea, as well as Jeremy Ashkenas' reaction to SemVer, both try to address the underlying assumption that all you need is a version number to know if you should upgrade. First, in practice there are too many packages that don't adhere to SemVer, or appear to do so but in reality are not sufficiently tested for SemVer to be of any use. Second, if your code depends on any package, you are ultimately responsible for every potential breakage whether due to upgrades, security flaws, or bugs. Of course no one can control everything, but SemVer can give a false sense of security. Personally I prefer to look at a changelog because it has a lot more detail than a version number can ever convey.
- chton 12y agoI agree that the 'false sense of security' problem is one of the biggest issues that SemVer faces, but it can be remedied in a variety of ways. Nuget, for example, is strongly focused on SemVer, and most (recent) packages tend to follow it. It's a cultural issue more than a technical one. It's also very true that the responsibility is on the developer doing the upgrade, but the package maker should not make that job harder or more risky than it already is. Creating hard-to-distinguish variations that can have a big impact is not a good way to make upgrades easier.