4 ms·
TIL! Thanks! I always assumed that if you were doing Semver right, then you could end up at 0.124.2 or something. Glad to learn that’s not the case.
by cuddlybacon 6y ago
TIL! Thanks!
I always assumed that if you were doing Semver right, then you could end up at 0.124.2 or something. Glad to learn that’s not the case.
- MaxBarraclough 6y agoPerhaps I'm missing something obvious, but, why not?
- jml7c5 6y agoExample: semver does not require libfoo 0.4.1 and libfoo 0.4.2 to be compatible in any way. Anything can change between them. It's not until MAJOR >= 1 that the MINOR and PATCH numbers have semantic meaning. Say libfoo 0.4.1's furbinate() function draws a pretty picture. When libfoo 0.4.2 comes out and someone calls furbinate(), they may be surprised to have all their files deleted and their screen covered with filthy Latin poetry, but it is allowed per the semantic versioning spec.
- fingerlocks 6y agoSure, but still doesn’t explain why one can’t end up at 0.142.2 as noted by GP. Something is missing from this discussion, ninja edit?
- DougBTX 6y agoA version 0.142.2 is perfectly possible with Semver, it just implies that the the developer has had a lot of iterations on the idea, but never got to the point that they consider stable. If the software had a stable API at that point, but they were still using a 0.x.y version number, then they wouldn't be using Semver properly, since 0.x.y versions are for unstable initial development releases. https://semver.org/#spec-item-4 https://semver.org/#spec-item-4
- fingerlocks 6y agoRight, I know. But GP implied it was impossible, not just unlikely. Hence the confusion all around.
- cuddlybacon 6y agoI guess my wording was unclear. I thought with semver if you never did a major breaking change then you had to keep the major version 0 forever.