3 ms·

But you've just nailed the problem: this is NOT the convention used within Rust. In Rust, 0.x.y would treat .y as NON-BREAKING, BACKWARDS-COMPATIBLE changes.

• cmeacham98 4y ago
  This is incorrect. Using Semantic Versioning is the standard convention in Rust.
  • burntsushi 4y ago
    Hi, I'm on libs-api. You are incorrect. Cargo always has, since its inception, treated changes to the leftmost non-zero number in the version as semver incompatible releases. That means 0.0.1 and 0.0.2 are semver incompatible. That means 0.1.2 and 0.2.8 are semver incompatible. 0.1.2 and 0.1.8 are semver compatible. semver says that in 0.x.y, "anything goes." But that is just not true with Cargo. This is also documented, emphasis mine: > This guide uses the terms "major" and "minor" assuming this relates to a "1.0.0" release or later. Initial development releases starting with "0.y.z" can treat changes in "y" as a major release, and "z" as a minor release. "0.0.z" releases are always major changes. This is because Cargo uses the convention that only changes in the left-most non-zero component are considered incompatible. https://doc.rust-lang.org/cargo/reference/semver.html https://doc.rust-lang.org/cargo/reference/semver.html
    • steveklabnik 4y ago
      It’s more complicated than that. Maybe I’ll finally actually write a blog post. While the semver spec has contained that line about 0.y.z, the semver spec also does not define ranges, that is, how specifying version requirements works. Cargo implements these things, like ^ and > and etc, the exact same way that every other semver implementation implements them. That’s because very quickly the “use minor like major when major == 0” thing became the de facto way that people used semver in its earlier days. Implementations understood this, but the spec was never changed. So Cargo does follow semver in practice, like everyone else. There’s a combination of discrepancy and under-specification in the spec; which is a great reminder that specifications tend to follow implementations, not the other way around. It’s on my long list of things to do to eventually reconcile this in the semver specification, but it’s been a few years and I still haven’t managed it, so no promises there.
      • burntsushi 4y ago
        Hmmm I'm struggling to see the difference between what you're saying and what I'm (and the Cargo docs) are saying. semver says anything goes at 0.x.y: > Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable. It is also simultaneously the case that "anything may change at 0.x.y" is not true for Cargo. Cargo is stricter than "anything may change." Maybe what you're saying is that Cargo is consistent with semver, but "just" stricter? I'd agree with that, absolutely. That is why I try hard to not say "Cargo doesn't follow semver." (Although it's easy to slip on that one.)
        • steveklabnik 4y ago
          Yeah I should probably actually write the post, haha. Commenting between sets at the gym just isn’t the same. I’ll let you know if/when I do. This comment of yours already helped me formulate a bit of it, I think, so thanks for that. “Just stricter” is much more accurate than “doesn’t follow”, for sure. “No semver implementation follows the major version zero sentence in the semver spec, and Cargo does what they all do” is maybe an even closer approximation. We’ll see how good I can do with more than 60 seconds rest between typing :)
          • burntsushi 4y ago
            Ah okay great, sounds good! And yes, having something canonical to link to that explains this would be useful indeed.
      • trhr 4y ago
        Rust's semver spec is very good, common-sense guidance that matches the level of risk most of us are comfortable with: - Don't put 0.0.x in prod ever. - Probably don't put 0.1.x in prod, either. - Maybe put 0.40.x in prod. Pin to 0.40 if you do. - Put 1.x.x in prod, because they're basically done with it. I get upset when these conventions aren't followed and I'm using something expecting them to be.