3 ms·

I'm not saying they're breaking the law and should be arrested, I'm saying if they're breaking shit in patch release, even on v0, I refuse to touch it until v1.

by trhr 4y ago

I'm not saying they're breaking the law and should be arrested, I'm saying if they're breaking shit in patch release, even on v0, I refuse to touch it until v1. If you're not breaking shit in patch releases, I'll touch v0 and pin to a minor. People can run anything they want however the fuck they want, I just won't use it. How's that?

spoiler 4y ago
FWIW, I've been tinkering with Bevy since like 0.6 I think, and don't remember many (if any?) patch breaking changes. I did skip 0.7 since I remember upgrading from 0.6 to 0.8 directly, though. The minor jumps are sometimes very small changes, sometimes giant ones (but alas, it's still a 0.x project, so I got not qualms)
cmeacham98 4y ago
You said > doesn't specify if breaking changes will occur between major, minor, or patch versions What I'm telling you is that it _does_ specify that: by using a 0.x.y version they are explicitly specifying that breaking changes can occur between _any_ version. If you don't want to use Bevy because of that, then that's fine.
- trhr 4y ago
  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. I don't think I'm stepping beyond the pale of reasonable engineering when I suggest that a package in the Rust ecosystem that doesn't follow the Rust semver guidance -- and doesn't EXPLICITLY STATE that they don't follow the Rust semver guidance -- is a library I won't touch. The fact that there's so much confusion on this thread about what their semver policy actually is shows exactly why it should be stated upfront and not masked behind a generic "stability warning."
  - 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
IceSentry 4y ago
> I'm saying if they're breaking shit in patch release You just assumed this, but this isn't true. Bevy uses semver like most of the rust ecosystem. The warning is just telling people that the breaking changes will be frequent. It doesn't mean they will be in a patch release. I don't understand what's to be confused about here. Bevy never specified any custom release strategy because there isn't one, it's just semver like almost everything else in rust.

by trhr 4y ago

spoiler 4y ago

FWIW, I've been tinkering with Bevy since like 0.6 I think, and don't remember many (if any?) patch breaking changes. I did skip 0.7 since I remember upgrading from 0.6 to 0.8 directly, though. The minor jumps are sometimes very small changes, sometimes giant ones (but alas, it's still a 0.x project, so I got not qualms)

cmeacham98 4y ago

You said > doesn't specify if breaking changes will occur between major, minor, or patch versions What I'm telling you is that it _does_ specify that: by using a 0.x.y version they are explicitly specifying that breaking changes can occur between _any_ version. If you don't want to use Bevy because of that, then that's fine.

trhr 4y ago
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. I don't think I'm stepping beyond the pale of reasonable engineering when I suggest that a package in the Rust ecosystem that doesn't follow the Rust semver guidance -- and doesn't EXPLICITLY STATE that they don't follow the Rust semver guidance -- is a library I won't touch. The fact that there's so much confusion on this thread about what their semver policy actually is shows exactly why it should be stated upfront and not masked behind a generic "stability warning."
- 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

IceSentry 4y ago

> I'm saying if they're breaking shit in patch release You just assumed this, but this isn't true. Bevy uses semver like most of the rust ecosystem. The warning is just telling people that the breaking changes will be frequent. It doesn't mean they will be in a patch release. I don't understand what's to be confused about here. Bevy never specified any custom release strategy because there isn't one, it's just semver like almost everything else in rust.