3 ms·
> Furthermore, it’s very much been my experience that semver changes, like all code comments, only communicate the intent of the developer and not always the re
by BugsJustFindMe 2y ago
> Furthermore, it’s very much been my experience that semver changes, like all code comments, only communicate the intent of the developer and not always the reality.
This is the truth and the reason why SemVer is fundamentally wrong for almost all cases that people use it for. Fools with keyboards and big salaries hallucinate a contractual certainty where none exists.
- rswail 2y agoIf you understand that the "sem" in semver is specifically about semantics and not about anything else, and that an API includes its current semantics in the semver, then it makes sense. The issues I've struck with other developers: 1. Defining the boundaries of the API 2. Defining the semantics of the API from the perspective of the user
- deleted 2y ago[deleted]
- jraph 2y agoTools like revapi help you get close enough. It's not perfect but still useful. Don't let perfect be the enemy of good. In most case, we probably don't need lawyer-level guaranties, but the guidance is helpful.
- hifromwork 2y agoI'd like to hear your alternative. What do you propose? That we stop even trying to tackle this problem, and all libraries are sequentially or date-versioned? And you can pin to, for example, library version built from march last year to today? That would be a huge mess, IMO. Of course for non-libraries semver is fairly pointless, but for libraries it describes a contract and that contract works well in practice. But maybe there is a better way - hence my question.
- BugsJustFindMe 2y agoRead more of my thoughts here https://news.ycombinator.com/item?id=37426532 https://news.ycombinator.com/item?id=37426532 > for libraries it describes a contract This is false for reasons explained in the link.