Hacker News new | ask | show | jobs
by matt_kantor 89 days ago
> Versions before 1.0 do not strictly follow semantic versioning.

Sorry for being nitpicky, but yes they do. Semantic versioning[0] allows arbitrary changes while the major version is 0:

> Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

[0]: https://semver.org/

2 comments

Hi, the comment I left in README.md is just to warn user that do expect breaking changes before 1.0 for THIS PROJECT specifically. there is no implication that semver as a standard is promoting arbitrary changes/version before 1.0.
I get that, and it's a nice thing to warn users about. My nitpick was merely about the specific "do not strictly follow semantic versioning" phrasing. There's nothing you can do in a 0.y.z release which doesn't follow the SemVer spec (e.g. your next release could turn the project into a spell checker instead of a CLI framework and you'd still be in compliance).
ohh thank you for pointing that out. I just double checked the semver docs and it makes sense now. Something new I learned today
thanks for the catch, what we meant is that we’re not committing to strict stability guarantees yet, so APIs may still change as we iterate toward 1.0.
I understand, but that's already implied by a 0.y.z version number.
I will say that this doesn't seem to be how semver is used in the wild, which I would argue is more important. I personally didn't know about this rule. Tons of Rust projects follow semver don't follow it either, and just stay on 0.x.y forever.
How is it used in the wild, in your experience? Have you observed projects following some alternate set of rules?

I thought projects that stay on 0.x.y forever mostly do it because it means they're allowed to break things. Also, since 0.x.y means "anything goes", projects can introduce their own conventions within that range without violating the spec.

I know that some package managers (including Cargo and npm) confusingly treat 0.1.0 → 0.1.1 like a "minor" update, despite the spec. Is this what you're referring to?

Yes, that was what I was referring to, although I thought the reason of staying at 0.y.z was more of a cultural one. v0, at least to me, implies that the API may change arbitrarily and quickly, but makes no assertions about the actual versioning scheme itself.

There's a website making fun of it: https://0ver.org/