The problem is that "the prototyping phase" isn't a real phase, and this doesn't specify if breaking changes will occur between major, minor, or patch versions. It gives developers no guidance of what semver to track based on their own willingness to endure breaking changes. Using a library that still can't tell you that is just asking for trouble.
> 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.
The 0.x is essentially used as way to tell people to use at their own risk since it isn't considered stable yet. Using a library like this isn't asking for trouble if you know what you are dealing with and in the context of bevy it currently means a breaking change every 3 months with a blog post and migration guide.
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?
> 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.
> 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.
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."
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.
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.
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.)
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 :)
> this doesn't specify if breaking changes will occur between major, minor, or patch versions
The entire Rust ecosystem works on a model of breaking changes for 0.x version happening in minor but not patch releases. In fact, I'm struggling to think of any software project that intentionally releases breaking changes in patch releases.
I'm not sure what we're arguing about. You say "don't break bugfix releases." I say "don't break bugfix releases." Docs don't say "we don't break bugfix releases." Instead, docs say "we break all the time don't trust us" instead of "pin to a minor version if you don't want to break all the time."
It's specifically not a question of knowing how the Rust community usually does these things, it's a question of "does this package conform to Rust's semver conventions, the official semver conventions, or something custom?"
The statement, _as its written in the docs_ implies "we do something custom." Whether that's true or not is irrelevant. I read it, interpreted it as a lack of governance or adherence to standards, and moved on. Any professional engineer would do the same.
No, the statement says that there will be frequent breaking APIs, it doesn't make any claim about release strategy. Releasing breaking changes on every 0.minor release perfectly fits in this definition.
Making a quick judgement based on an assumption that's provably wrong isn't really the definition of a professional engineer.
Tell me you've never had a job without telling me you've never had a job. Not having a release strategy at all is insta-trashcan at any enterprise I've ever worked at.
The problem is that "the prototyping phase" isn't a real phase, and this doesn't specify if breaking changes will occur between major, minor, or patch versions. It gives developers no guidance of what semver to track based on their own willingness to endure breaking changes. Using a library that still can't tell you that is just asking for trouble.