4 ms·

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

> 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/
- paskozdilar 5y ago
  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.
  - wh33zle 5y ago
    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.

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/

paskozdilar 5y ago
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.
- wh33zle 5y ago
  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.