Hacker News Reader

Comment by s3cur3 | Hacker News Reader

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

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.

View on HN

> 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.

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.

> 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.

So in your mind because bugs exist there is no purpose in communicating whether an update intentionally changes things? I can not see your logic.

Bugs will always exist. No meaningfully complicated software will ever be bug free. By your logic we should just never upgrade anything? Except that there are time-based bugs all over the place, so not upgrading anything is also guaranteed to break things (2038 anyone?)

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.

> (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.

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.

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.

That's only if you consider line numbers as part of the public API, which would be crazy.

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.

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.

good point

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/

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.

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.

Wouldn't it be so smart to exclude comments in the size calculation?

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.

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.

Reply on news.ycombinator.com