16 ms·
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.
by jellyotsiro 6mo ago
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.
- matt_kantor 6mo agoI understand, but that's already implied by a 0.y.z version number.
- olivia-banks 6mo agoI 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.
- matt_kantor 6mo agoHow 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?
- olivia-banks 6mo agoYes, 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/ https://0ver.org/