Hacker News Reader

Comment by Groxx | Hacker News Reader

There absolutely is fuzziness in incompatibility.

I can change one part of an API and leave another untouched - that's part compatible, part incompatible. It's only an issue if you used the changed part.

(If you think that first one always counts... what if the changed part is literally called YouMustNotUseThisFunctionOrYourCodeWillAlwaysBreak() ? It's clearly implied to not be part of your intended API, despite technically being part of it.)

I can add something to a type, in a way that's backwards compatible at compile time... but common reflection patterns might cause everyone's code to explode.

I can make a change that solves a bug that someone was accidentally relying on by doing the wrong thing, but doesn't affect compile-time behavior, nor runtime for anyone using the library the way they should. But that bug-user's code is now broken, is this an incompatible change?

View on HN

> I can change one part of an API and leave another untouched - that's part compatible, part incompatible. It's only an issue if you used the changed part.

When you commit to a version 1, you assume that every user of the package is using every feature you provide through your official API. If you break any slightest piece of the API, you've broken compatibility. It might "kinda work" for many users, but it will almost surely cause significant pain for many others.

> I can make a change that solves a bug that someone was accidentally relying on by doing the wrong thing, but doesn't affect compile-time behavior, nor runtime for anyone using the library the way they should. But that bug-user's code is now broken, is this an incompatible change?

It is not an incompatible change, and it is the responsibility of the bug-user's code to fix the bug in his program.

Of course, when such a thing happens on a large-enough scale, the API developer sometimes cannot afford to "fix" the behavior and force countless users to fix their programs, so the quirk just becomes de-facto part of the API.

Even as someone who has a lot of sympathy for strong backwards-compatibility guarantees, the position you have put forth here is ridiculous to the point of absurdity and is a level of backwards-compatibility that I assure you you have never once experienced from any library (including SQLite, which is generally considered to be extremely pedantic about compatibility and yet hasn't even attempted to live up to your impossible standard).

It's not necessarily a commitment to an impossible level of backwards compatibility, but rather a commitment to communicate any failure to attain that level clearly by bumping your major version number. I've found that to be pretty doable. (Which does usually come with a commitment to at least strive to attain that level, and to batch changes that do not live up to it.)

That's a good point.

Semver doesn't force you to do anything. You can stay on v0 forever for all it cares, or you can bump a major version every day.

What semver doesn't allow you to do is lie to your users.

> When you commit to a version 1, you assume that every user of the package is using every feature you provide through your official API. If you break any slightest piece of the API, you've broken compatibility.

That is not how semver works. If you read the documentation [0], it says right there that the public API must be clearly defined but that can also happen through documentation and you only have to up the major version if you break that specified public API.

You can certainly consider it bad programming practice to expose something via the means of the language that is not defined as public API but it is not against semver to do so.

[0]: https://semver.org/

If you think that way, then everything is incompatible, because the person using your lib could always do a hash of your lib file and create code that depends on it:

    if hash(libpath) != predefinedHash {
        log.Fatal("broken compatibility teehee")
    }

In the context of semver, "API" means "public API". There is no other API but public API.

Yes perhaps I misunderstood you. I was trying to point out that semver is okay with having elements in the "public" API of a library (public in the sense of you can import and use it, i.e. not hidden in private modules etc) but explicitly documenting that it is not considered public API in regards to semver.

If that is what you meant with "official API" then we are on the same page.

> I can make a change that solves a bug that someone was accidentally relying on by doing the wrong thing ...

There is even a "law" for that: https://www.hyrumslaw.com/

Not when it comes to Go's compiler, which is a binary acceptance function.

>There absolutely is fuzziness in incompatibility.

And that's not something to accept and work around, but a problem, one that Go's hard stance solves.

Reply on news.ycombinator.com