0.0.z not compatible with 0.0.z+1

[steveklabnik]

@eddyb brought this up in #rust-internals today. If y != 0, any z is compatible, but if y == 0, they're not. This feels wrong.

I haven't reproduced yet, though.

[lambda-fairy]

Having 0.0.z not compatible with 0.0.(z+1) is consistent with npm.

[eddyb]

In that case we should discourage publishing these or ban it fully. 0.0.x is useless because you simply can't give users a fix if a bug was discovered.

[kentfredric]

0.0.x is useless because you simply can't give users a fix if a bug was discovered.

My impression that there's a good intention behind this, as 0.x is "unstable", and 0.0.x is "ultra unstable".

Subsequently, I think the use for 0.0.x is for people who are still rapidly changing their project early in the development cycle, where there should be no expectation of inter-compatibility.

Just the communication around this isn't loud enough, so people may either mis-use this version range for their published crates when they aught to migrate to 0.(>=1).*.

And further, people depend on 0.0.x crates expecting some degree of stability that isn't there, and people depending on 0.0.x should not expect to receive updates, as any updates are likely to also come with API breaking changes.

Sure, as-is, it is surprising behaviour, but the surprise comes from a missmatch between what you've learned and what is true.

I'd probably argue in favour of better warnings or documentation regarding the use of 0.0.x ( both in publishing the package, and in the consumption of the package ), than argue 0.0.x to be banned outright.

( It would be especially useful if you're developing a small gaggle of interdependent crates, and rapidly changing their APIs, being able to develop and test them efficiently via cargo, without being forced to promise users a support level you're not ready for )

[eddyb]

And further, people depend on 0.0.x crates expecting some degree of stability that isn't there, and people depending on 0.0.x should not expect to receive updates, as any updates are likely to also come with API breaking changes.

The problem isn't in normal usage, but when a 0.0.x crate has a bug that can be fixed with a backwards-compat release, except there's nothing like 0.0.x.1 to actually release it as.

This could even be a Rust soundness bug which can only be fixed with a breaking change in the compiler, so being able to release fixed versions of crates can be useful.

Subsequently, I think the use for 0.0.x is for people who are still rapidly changing their project early in the development cycle, where there should be no expectation of inter-compatibility.

You can use 0.x in exactly the same way. 0.0.x is redundant with that, but is strictly worse because you can't release a patch when other crates (inevitably) depend on yours.

[dtolnay]

I believe the current behavior matches the description of caret requirements in https://github.com/semver/semver/blob/efcff2c838c9945f79bfd21c1df0073271bcc29c/ranges.md, and matches Cargo's intended behavior, so I'll go ahead and close this.