4 ms·
The Motivation is dependency hell, the Rationale says the version is easy to understand at a glance. So, Rationale has missed the opportunity to explain how thi
by andrey_utkin 7y ago
The Motivation is dependency hell, the Rationale says the version is easy to understand at a glance. So, Rationale has missed the opportunity to explain how this is a solution to the declared problem.
- rodw 7y agoExactly. I don't get it. What's the advantage here? If the complaint is "semver numbers aren't always used the way they are meant to be" how does (what is effectively) `v<year>.<month>.<day>` solve that problem? With SemVer the numbers are at least _sometimes_ used as designed. If the complaint is "I want to know how old the software is" then why not just append a timestamp to the SemVer number as in `v2.3.4-<date>` What's the advantage of making the date primary? Does the breaking-change identifier only refer to the previous version chronologically? Then this system is incompatiable with any scenario in which you need to "patch" old versions of the software. And isn't that a pretty central problem that version numbers are meant to address? I honestly don't understand the problem chronological versioning is solving, or if I do than it seems to me that `<semver>-<date>` is obviously a better way to solve it.
- Izkata 7y agoHonestly, the intent there seems easy: it's hard to tell at a glance that library A version 230 is compatible with library B version 1.2.4 However, if they both used date-based versioning, then the compatible versions would in theory have the same-ish version of 2019.12.* when compatible with each other. For the same reasons as in tons of other comments, I also don't think this theory would work out.
- deleted 7y ago[deleted]