3 ms·

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'

• ithkuil 5y ago
  > 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/ https://www.hyrumslaw.com/
• paskozdilar 5y ago
  > 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.
  • saurik 5y ago
    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).
    • Vinnl 5y ago
      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.)
      • paskozdilar 5y ago
        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.
  • wh33zle 5y ago
    > 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/ https://semver.org/
    • 5y ago
• coldtea 5y ago
  >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.
• echlebek 5y ago
  Not when it comes to Go's compiler, which is a binary acceptance function.