5 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 8mo 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 8mo agoI understand, but that's already implied by a 0.y.z version number.
- olivia-banks 8mo 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 8mo 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 8mo 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/