3 ms·

I’ve been happily using date base version numbers in any user facing product (e.g apps) for a while now. It’s been great. While semver makes great sense on pap

I’ve been happily using date base version numbers in any user facing product (e.g apps) for a while now. It’s been great. While semver makes great sense on paper, and even allows nifty little algebras in dependency declarations, it is been my experience that the delineations are not always as easy to decode and different team members can quibble over the exact realization of the boundaries. 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. A minor roll may be anticipated as backwards compatible, until an unrealized use case pops up and makes the minor change very breaking.

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 ago
  If 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 ago
  Tools 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 ago
  I'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 ago
    Read 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.
arp242 2y ago
semver is useful for libraries and other things that have a very clear programmer interface. For most applications it's fairly pointless. There are often many "breaking changes" in any significant release, and there is no strong agreement at all on what a "breaking change" even is.
layer8 2y ago
> only communicate the intent of the developer and not always the reality. It’s nevertheless a very useful heuristics for anything with a programmatic interface. Nothing is a 100% perfect.

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 ago
If 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 ago
Tools 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 ago
I'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 ago
  Read 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.

arp242 2y ago

semver is useful for libraries and other things that have a very clear programmer interface. For most applications it's fairly pointless. There are often many "breaking changes" in any significant release, and there is no strong agreement at all on what a "breaking change" even is.

layer8 2y ago

> only communicate the intent of the developer and not always the reality. It’s nevertheless a very useful heuristics for anything with a programmatic interface. Nothing is a 100% perfect.