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