3 ms·

https://medium.com/@xzyfer/why-node-sass-broke-your-code-and-semver-1b3e409c57b9 https://medium.com/@xzyfer/why-node-sass-broke-your-code-and... What do you th

https://medium.com/@xzyfer/why-node-sass-broke-your-code-and-semver-1b3e409c57b9 https://medium.com/@xzyfer/why-node-sass-broke-your-code-and... What do you think of this example, where a library made a breaking, non-backwards compatible change, causing user code to throw fatal errors. They defended their point that this is only a minor version increment since the working user code was actually erroneously working and should have been throwing fatal errors the whole time.

WhyNotHugo 5y ago
If it broke the exposed API, it should not be a minor. It doesn't matter if it's "by design" or not, people still rely on it and semver is how you communicate the breakage to them.
- beckingz 5y ago
  What if it counts as a bug fix?
  - dagw 5y ago
    It really depends on the bug? If it is a bug that causes your program to crash or return obviously invalid output then it's probably OK to fix it. But if the 'bug' does something useful that just happens to be undocumented or contradicts the documentation, then you need to be a lot more careful about 'fixing' it. Especially if it's clear that lots of people are relying on that bug as a feature.
  - squeaky-clean 5y ago
    I ran into this recently, I'm sure many others did too (I'm not the issue poster). https://github.com/eventlet/eventlet/issues/702 https://github.com/eventlet/eventlet/issues/702 https://github.com/benoitc/gunicorn/pull/2581 https://github.com/benoitc/gunicorn/pull/2581 While the bug does seem pretty critical for websocket users, the patch-version-change ended up breaking any application that uses gunicorn with eventlet (even if you don't use websockets). It feels slightly like my fault, because eventlet has been at v0.x.x for 9 years now. I used to be a bit hesitant about using anything that couldn't declare a version 1.0.0. I guess I've learned my lesson and just won't use any v0 library except in hobby projects now.
- joshuamorton 5y ago
  Per hyrums law, this would mean that essentially all changes should result in a major version bump, which defeats the purpose.
  - okamiueru 5y ago
    It also makes "Hyrum's Law" pretty useless, doesn't it? Who names something like that after themselves? Well, I know at least one such case.
    - joshuamorton 5y ago
      > It also makes "Hyrum's Law" pretty useless, doesn't it? Not really. Hyrum's law is descriptive of reality and borne out of experience trying to update/change things. The point of it is to remind you that even when you think you aren't breaking things, you probably are breaking someone's workflow, and that your API surface is much larger than you think it is (performance, threading, ordering characteristics, etc. are all things that your dependencies will routinely rely on). > Who names something like that after themselves? Well, I know at least one such case. He didn't. Titus Winters probably deserves credit for the name. Hyrum deserves credit for the observation.
      - okamiueru 5y ago
        He sure makes no small attempt at marketing the term, and himself https://www.hyrumslaw.com/ https://www.hyrumslaw.com/ In any case, my point is that it this observation has no relevance on the applicability of semantic versioning. One is a practical approach at making the best out of versioning. The other is a rather simple observation that given sufficient enough users of an API, all parts of the API will be depended on by someone. To go and suggest that the logical extreme of a though experiment that, any change (bug fix or what have you) on an API, and given wide enough usage, will change/break something for someone, should somehow conclude in a defeatist mentality of "what's the point, everything becomes a major version", is... in my honest opinion, as uninteresting of an observation as they come. I'm sure it has more interesting applications elsewhere. But then again, maybe I don't get what is supposed to be profound, or applicable, and I'm all ears.
okamiueru 5y ago
Versioning is always a little bit tricky. First of all, it depends what you are versioning. If it is an API (be that web-api or programmatic API through a public interface), then semantic versioning is exceedingly useful, and how to go about it is less ambiguous. To address the issue you linked to, it really doesn't matter if it is a bug-fix or not. Semver 2.0 describes PATCH in the summary as > PATCH version when you make backwards compatible bug fixes. And the words backwards compatible are key. If it isn't, it doesn't matter that it fixes a bug or adds a breaking feature. If the code will break for your users unless they change their code, then you cannot fix it by bumping the PATCH version. Now, semantic versioning isn't the end all be all. There are other versioning schemas that suit some developments. But, if there is a pretense of actually following semantic versioning, then the argument presented in defense really isn't relevant. Bumping the major version isn't something holy and beyond reproach. Just use it for what it is intended. Package systems very often rely on semver being followed. Does the new version break existing use? Then bump the major version. That's the responsible thing to do, and it should only be met with understanding. To quote SemVer 2.0: > 6. Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.

WhyNotHugo 5y ago

If it broke the exposed API, it should not be a minor. It doesn't matter if it's "by design" or not, people still rely on it and semver is how you communicate the breakage to them.

beckingz 5y ago
What if it counts as a bug fix?
- dagw 5y ago
  It really depends on the bug? If it is a bug that causes your program to crash or return obviously invalid output then it's probably OK to fix it. But if the 'bug' does something useful that just happens to be undocumented or contradicts the documentation, then you need to be a lot more careful about 'fixing' it. Especially if it's clear that lots of people are relying on that bug as a feature.
- squeaky-clean 5y ago
  I ran into this recently, I'm sure many others did too (I'm not the issue poster). https://github.com/eventlet/eventlet/issues/702 https://github.com/eventlet/eventlet/issues/702 https://github.com/benoitc/gunicorn/pull/2581 https://github.com/benoitc/gunicorn/pull/2581 While the bug does seem pretty critical for websocket users, the patch-version-change ended up breaking any application that uses gunicorn with eventlet (even if you don't use websockets). It feels slightly like my fault, because eventlet has been at v0.x.x for 9 years now. I used to be a bit hesitant about using anything that couldn't declare a version 1.0.0. I guess I've learned my lesson and just won't use any v0 library except in hobby projects now.
joshuamorton 5y ago
Per hyrums law, this would mean that essentially all changes should result in a major version bump, which defeats the purpose.
- okamiueru 5y ago
  It also makes "Hyrum's Law" pretty useless, doesn't it? Who names something like that after themselves? Well, I know at least one such case.
  - joshuamorton 5y ago
    > It also makes "Hyrum's Law" pretty useless, doesn't it? Not really. Hyrum's law is descriptive of reality and borne out of experience trying to update/change things. The point of it is to remind you that even when you think you aren't breaking things, you probably are breaking someone's workflow, and that your API surface is much larger than you think it is (performance, threading, ordering characteristics, etc. are all things that your dependencies will routinely rely on). > Who names something like that after themselves? Well, I know at least one such case. He didn't. Titus Winters probably deserves credit for the name. Hyrum deserves credit for the observation.
    - okamiueru 5y ago
      He sure makes no small attempt at marketing the term, and himself https://www.hyrumslaw.com/ https://www.hyrumslaw.com/ In any case, my point is that it this observation has no relevance on the applicability of semantic versioning. One is a practical approach at making the best out of versioning. The other is a rather simple observation that given sufficient enough users of an API, all parts of the API will be depended on by someone. To go and suggest that the logical extreme of a though experiment that, any change (bug fix or what have you) on an API, and given wide enough usage, will change/break something for someone, should somehow conclude in a defeatist mentality of "what's the point, everything becomes a major version", is... in my honest opinion, as uninteresting of an observation as they come. I'm sure it has more interesting applications elsewhere. But then again, maybe I don't get what is supposed to be profound, or applicable, and I'm all ears.

okamiueru 5y ago

Versioning is always a little bit tricky. First of all, it depends what you are versioning. If it is an API (be that web-api or programmatic API through a public interface), then semantic versioning is exceedingly useful, and how to go about it is less ambiguous. To address the issue you linked to, it really doesn't matter if it is a bug-fix or not. Semver 2.0 describes PATCH in the summary as > PATCH version when you make backwards compatible bug fixes. And the words backwards compatible are key. If it isn't, it doesn't matter that it fixes a bug or adds a breaking feature. If the code will break for your users unless they change their code, then you cannot fix it by bumping the PATCH version. Now, semantic versioning isn't the end all be all. There are other versioning schemas that suit some developments. But, if there is a pretense of actually following semantic versioning, then the argument presented in defense really isn't relevant. Bumping the major version isn't something holy and beyond reproach. Just use it for what it is intended. Package systems very often rely on semver being followed. Does the new version break existing use? Then bump the major version. That's the responsible thing to do, and it should only be met with understanding. To quote SemVer 2.0: > 6. Patch version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible bug fixes are introduced. A bug fix is defined as an internal change that fixes incorrect behavior.