3 ms·
> 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 sligh
by 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 agoIf 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 agoYes 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.