C-STABLE too restrictive?

[tobiasvl]

C-STABLE says:

A crate cannot be stable (>=1.0.0) without all of its public dependencies being stable.

However, Cargo treats unstable versions in a special way:

The version 0.0.x is not considered compatible with any other version.

Since this means that Cargo will not allow any updates of an unstable dependency specified as version 0.0.x because it might contain breaking changes, it seems to me that a stable crate can have an unstable dependency that is specified as version 0.0.x, and that C-STABLE should only apply to crates that have dependencies on the forms 0.x or 0.

[BurntSushi]

I'm not sure I follow, and I don't understand why 0.0.x should be treated any different than 0.x?

The idea of this guideline, I think, is to say that you can "only be as 'stable' as your public dependencies."

[wookietreiber]

Isn't 0.x required to be stable, i.e. breaking changes requiring 0.(x+1)?

[Enet4]

The C-STABLE guideline advocates for library maintainers providing a v1 when the API is considered stable (as in, less likely to change substantially at that point). This all seems orthogonal to what constitutes a breaking change. There are many ways in which a maintainer could comply with semantic versioning, even per the slightly different specification followed by Cargo, yet without complying with this guideline.

Moreover, keep close that the guideline mentions public dependencies. The point of this is to prevent an otherwise stable API from transitively being subjected to instability from its dependencies, at the risk of stagnating or requiring major version bumps. A stable crate can have dependencies with version 0.x or even 0.0.x, so long as that they do not leak into the public API.

With that said, I don't understand this issue well, nor how the subsequent implications about the guideline were made. They don't seem to make much sense.

[tobiasvl]

@Enet4, I think you understood this issue perfectly! And you also understood that I've erroneously conflated "stability" with "avoids breaking changes". The reason I made this issue is that the Rust ecosystem obviously has a lot of crates that seem to never go >= 1.0.0, and partly because of this guideline, this instability is "viral" and causes dependents to also be stuck at < 1.0.0. I mistakenly thought that this guideline wanted to avoid unstable dependencies making breaking changes unexpectedly.

I suppose one reason for my conflation is that the guideline uses the word "stable", but it doesn't define it. Well, it does define it, but not beyond "a crate being >= 1.0.0 is required for stability" and "all public dependencies being stable is necessary for stability"... But presumably those two aren't the only sufficient and required conditions. Your "the crate is less likely to change substantially" is probably an unspoken condition (unless it's a guideline that I've missed). It might just be an obvious consequence of the fact that Cargo uses < 1.0.0 version numbers in a slightly different way than SemVer.