5 ms·

For another perspective on “semver is a lie,” see the “Live at Head” talk from Titus Winters of the Google core C++ team. https://m.youtube.com/watch?v=tISy7EJ

by s3cur3 6y ago

For another perspective on “semver is a lie,” see the “Live at Head” talk from Titus Winters of the Google core C++ team. https://m.youtube.com/watch?v=tISy7EJQPzI https://m.youtube.com/watch?v=tISy7EJQPzI TL;DW: By Hyrum’s law, at sufficient scale, there’s no such thing as a non-breaking change (including changing comments). Embrace that, and test sufficiently that you can always take the latest dependency but detect when it breaks.

Wowfunhappy 6y ago
> (including changing comments). Huh? I didn't watch, but practically speaking, how do you break something by editing comments? Let's assume it's an actual comment and not a shebang line or something.
- s3cur3 6y ago
  Because someone in your (presumably massive) org had some code somewhere that was parsing the source itself looking for... something. (The story Googlers tell is a program looking for a specific line number in a program’s output.) More on Hyrum’s Law: https://www.hyrumslaw.com/ https://www.hyrumslaw.com/
- marvy 6y ago
  I didn't watch it either, but... Does your language have exceptions? Do the exceptions support stack traces? Do those stack traces have line numbers? Well then... // old code: version 1.2.3 if(problem1) throw new Exception(); if(problem2) throw new Exception(); Meanwhile, we have client code that catches the exception and then inspects the line number to see whether it was caused by problem1 or by problem2. (You may say that this is crazy and no one would do such a thing. Maybe so. But this at least proves that it's theoretically possible. Also, you'd be surprised at what some people will do.) Anyway, we upgrade to the new code: // new code: version 1.2.4 // Helpful comment here; no other changes. if(problem1) throw new Exception(); if(problem2) throw new Exception(); And of course this comment messes up all the line numbers, at which point we can have anything from misleading error messages to system meltdown, depending on what the client code used the line number for.
  - erik_seaberg 6y ago
    I was pretty impressed with Microsoft's support system that would pull up the symbols from the release build that created a crash dump. It's not a good use of time to troubleshoot using some wrong version of the code that may or may not even have the same problem.
  - SahAssar 6y ago
    That's only if you consider line numbers as part of the public API, which would be crazy.
    - marvy 6y ago
      I'm guessing no one is crazy enough to consider line numbers part of the public API. And yet... I could imagine myself writing code like this if I were desperate enough, even though I would know perfectly well that my code would probably break the never next time I upgrade.
      - SahAssar 6y ago
        Sure, but that's because you know you've used a non-public API in which case semver has nothing to do with the conversation.
        marvy 6y ago
        good point
- jacobr1 6y ago
  Source code level reflection. Things like __LINE__ can change with new comments above them. An example is something like a logging statement that makes use of something like a line macro and a brittle test that matches against an exact logging entry.
- dragonwriter 6y ago
  You can break things by editing comments, but those things aren't, usually, part of the public API. SemVer is a claim about the public API, not the total of behavior you could potentially observe and react to.
- jsnell 6y ago
  Another classic was (is?) V8 using the textual size of a function as a heuristic when deciding whether to inline it in the jit. So changing a comment could have a large performance impact.
  - hbogert 6y ago
    Wouldn't it be so smart to exclude comments in the size calculation?
    - jsnell 6y ago
      Hard to say! It seems obvious, but given it is so obvious there might be a good reason to not do that. For example, if 99.9% of JavaScript in the wild weighted by popularity is minified, this could be the right tradeoff.
wolrah 6y ago
> at sufficient scale, there’s no such thing as a non-breaking change I don't disagree with you that unexpected breakage can come from the strangest things, especially as systems get larger and more complicated. That said, that's not what SemVer is about. SemVer is explicitly about public APIs. It's about communicating from upstream to downstream what level of changes they should expect from the new version. Breakage caused by unintentional bugs, badly designed clients making incorrect assumptions, and things that fiddle around with non-public interfaces is all out of scope. If I have an API that returns a named array as part of the response in version 1.0, and I add a few new entries to that array, that's version 1.1 to me. It should not break anything. It certainly can break something, for example if a naive developer decided to reference parts of the array by index value or just iterate through and assume they're always in the same order, but that does not mean it should be called a breaking change. From the perspective of SemVer, a non-breaking change means it will not break a client that correctly implements a public interface. If we have to care about incorrect implementations and non-public interfaces then it all becomes meaningless.
- regularfry 6y ago
  That's the point. It's meaningless. If I'm a client, and I've bumped my dependency from 1.2.3 to 1.3.0, it doesn't matter in that moment whether my deployment is on fire because there was an unannounced but intentional change, or a breakage because of a bug. Semver is supposed to give me confidence that that upgrade is safe, and it fundamentally can't.
  - have_faith 6y ago
    But it does prepare you for the scale of potential breakage? I always just saw semver as a scale of the possibility something could break without any guarantees. Major change is highly likely, minor change is potentially and patch is shouldn't but give it a quick check. That doesn't make it meaningless, it just makes it not black and white. No change no matter how small should give anyone confidence that something won't break. I don't think it reduces the value of semver though. It's just another attempt in a long line of attempts to categorise changes into something quickly digestible and it does that well enough.

by s3cur3 6y ago

Wowfunhappy 6y ago

> (including changing comments). Huh? I didn't watch, but practically speaking, how do you break something by editing comments? Let's assume it's an actual comment and not a shebang line or something.

s3cur3 6y ago
Because someone in your (presumably massive) org had some code somewhere that was parsing the source itself looking for... something. (The story Googlers tell is a program looking for a specific line number in a program’s output.) More on Hyrum’s Law: https://www.hyrumslaw.com/ https://www.hyrumslaw.com/
marvy 6y ago
I didn't watch it either, but... Does your language have exceptions? Do the exceptions support stack traces? Do those stack traces have line numbers? Well then... // old code: version 1.2.3 if(problem1) throw new Exception(); if(problem2) throw new Exception(); Meanwhile, we have client code that catches the exception and then inspects the line number to see whether it was caused by problem1 or by problem2. (You may say that this is crazy and no one would do such a thing. Maybe so. But this at least proves that it's theoretically possible. Also, you'd be surprised at what some people will do.) Anyway, we upgrade to the new code: // new code: version 1.2.4 // Helpful comment here; no other changes. if(problem1) throw new Exception(); if(problem2) throw new Exception(); And of course this comment messes up all the line numbers, at which point we can have anything from misleading error messages to system meltdown, depending on what the client code used the line number for.
- erik_seaberg 6y ago
  I was pretty impressed with Microsoft's support system that would pull up the symbols from the release build that created a crash dump. It's not a good use of time to troubleshoot using some wrong version of the code that may or may not even have the same problem.
- SahAssar 6y ago
  That's only if you consider line numbers as part of the public API, which would be crazy.
  - marvy 6y ago
    I'm guessing no one is crazy enough to consider line numbers part of the public API. And yet... I could imagine myself writing code like this if I were desperate enough, even though I would know perfectly well that my code would probably break the never next time I upgrade.
    - SahAssar 6y ago
      Sure, but that's because you know you've used a non-public API in which case semver has nothing to do with the conversation.
      - marvy 6y ago
        good point
jacobr1 6y ago
Source code level reflection. Things like __LINE__ can change with new comments above them. An example is something like a logging statement that makes use of something like a line macro and a brittle test that matches against an exact logging entry.
dragonwriter 6y ago
You can break things by editing comments, but those things aren't, usually, part of the public API. SemVer is a claim about the public API, not the total of behavior you could potentially observe and react to.
jsnell 6y ago
Another classic was (is?) V8 using the textual size of a function as a heuristic when deciding whether to inline it in the jit. So changing a comment could have a large performance impact.
- hbogert 6y ago
  Wouldn't it be so smart to exclude comments in the size calculation?
  - jsnell 6y ago
    Hard to say! It seems obvious, but given it is so obvious there might be a good reason to not do that. For example, if 99.9% of JavaScript in the wild weighted by popularity is minified, this could be the right tradeoff.

wolrah 6y ago

> at sufficient scale, there’s no such thing as a non-breaking change I don't disagree with you that unexpected breakage can come from the strangest things, especially as systems get larger and more complicated. That said, that's not what SemVer is about. SemVer is explicitly about public APIs. It's about communicating from upstream to downstream what level of changes they should expect from the new version. Breakage caused by unintentional bugs, badly designed clients making incorrect assumptions, and things that fiddle around with non-public interfaces is all out of scope. If I have an API that returns a named array as part of the response in version 1.0, and I add a few new entries to that array, that's version 1.1 to me. It should not break anything. It certainly can break something, for example if a naive developer decided to reference parts of the array by index value or just iterate through and assume they're always in the same order, but that does not mean it should be called a breaking change. From the perspective of SemVer, a non-breaking change means it will not break a client that correctly implements a public interface. If we have to care about incorrect implementations and non-public interfaces then it all becomes meaningless.

regularfry 6y ago
That's the point. It's meaningless. If I'm a client, and I've bumped my dependency from 1.2.3 to 1.3.0, it doesn't matter in that moment whether my deployment is on fire because there was an unannounced but intentional change, or a breakage because of a bug. Semver is supposed to give me confidence that that upgrade is safe, and it fundamentally can't.
- have_faith 6y ago
  But it does prepare you for the scale of potential breakage? I always just saw semver as a scale of the possibility something could break without any guarantees. Major change is highly likely, minor change is potentially and patch is shouldn't but give it a quick check. That doesn't make it meaningless, it just makes it not black and white. No change no matter how small should give anyone confidence that something won't break. I don't think it reduces the value of semver though. It's just another attempt in a long line of attempts to categorise changes into something quickly digestible and it does that well enough.