3 ms·

SemVer does not handle complex or nuanced information, which is one of the beefs the article has with it. SemVer does have answers for the question it asks "wha

by yoz-y 8y ago

SemVer does not handle complex or nuanced information, which is one of the beefs the article has with it. SemVer does have answers for the question it asks "what if you only broke it for 1% of users?" -> "tough luck, increase the major version" It seems that the author constructs a straw man for SemVer (albeit from real life examples) and then complains that it no longer serves its purpose. Contrary to the article SemVer is okay to determine whether there is a compatibility break, as long as it is followed to the letter. Is is overly strict? Yes it is, but it does guarantee results. Maybe an argument should be that not all libraries should not follow SemVer because it is a burden similar to certifications and regulatory procedures.

striking 8y ago
What if a patch or minor version change causes the library to break? This was a question a lot of people had to ask when npm didn't use package-lock.json and the `--save` option would automatically select a range of allowable versions. Your coworker could `npm install` something entirely different than you and have all sorts of bugs because of it. And there are plenty of documented cases of exactly this happening. The issue I see with semver is that it generally does not survive contact with the real world. People make mistakes when they package software, especially when they do it "without any warranty, express or implied". There's simply no substitute for testing whether a new package version will work or not; so in a realistic sense, semantic versioning simply doesn't work.
- yoz-y 8y ago
  I agree that the version number does not give you a guarantee, that the software is without bugs. However, it does work the other way around: if the major version was bumped then you know something has broken and you will have to modify your code. If it was a bug fix release and something breaks, it is on them, not on you (as in, rollback your dependency upgrade and complain on their bug tracker). That is, if you did not rely on buggy behavior in the first place. As a side effect, if you really try to follow SemVer it will force you to think ahead a bit more because the fact that you broke the API is reflected in something quite obvious, rather than buried in a change log somewhere.

by yoz-y 8y ago

striking 8y ago

What if a patch or minor version change causes the library to break? This was a question a lot of people had to ask when npm didn't use package-lock.json and the `--save` option would automatically select a range of allowable versions. Your coworker could `npm install` something entirely different than you and have all sorts of bugs because of it. And there are plenty of documented cases of exactly this happening. The issue I see with semver is that it generally does not survive contact with the real world. People make mistakes when they package software, especially when they do it "without any warranty, express or implied". There's simply no substitute for testing whether a new package version will work or not; so in a realistic sense, semantic versioning simply doesn't work.

yoz-y 8y ago
I agree that the version number does not give you a guarantee, that the software is without bugs. However, it does work the other way around: if the major version was bumped then you know something has broken and you will have to modify your code. If it was a bug fix release and something breaks, it is on them, not on you (as in, rollback your dependency upgrade and complain on their bug tracker). That is, if you did not rely on buggy behavior in the first place. As a side effect, if you really try to follow SemVer it will force you to think ahead a bit more because the fact that you broke the API is reflected in something quite obvious, rather than buried in a change log somewhere.