Add "unstable" indicator to pre-1.0 packages? about blessed-rs HOT 4 OPEN

I do actually think there is something to this suggestion. But it's a tricky one to do in practice because it's not a hard rule. The suggestion, as it stands, would mean applying pre-1.0 to the libc crate for example. What message would that be meant to convey? libc is as mature as it gets, but it is also pre-1.0. And it's not pre-1.0 because that's specifically what folks want or because it needs more iteration, it's pre-1.0 because putting out a semver incompatible release is hard to do without causing waves in the ecosystem. I'm not sure what to do about that, because at least in some cases, applying a pre-1.0 label isn't going to achieve the intended effect (of either pushing folks toward 1.0 or of communicating stability).

moved past the "anything MAY change at any time"-phase.

Note that this isn't really true in the Cargo ecosystem. That's because Cargo layers additional semantics on 0.x.y versions that aren't explicitly specified in the semver spec. The spec says "anything goes," but that's not actually what happens in the Rust ecosystem because Cargo treats any increment in the leftmost non-zero digit as semver incompatible. So that means if you do 0.1.2 -> 0.2.0, then Cargo will treat 0.2.0 the same way it would treat a 2.0.0 in a 1.2.0 -> 2.0.0 transition. This is the single thing that makes pre-1.0 versions tolerable: you still get many of the benefits semver. (The only real downside is that you only have two version components instead of three.)

from blessed-rs.

I don't think pre-1.0 version numbers are a useful metric in evaluating crate maturity/stability, so I don't think this is a good idea.

from blessed-rs.

I don't think pre-1.0 version numbers are a useful metric in evaluating crate maturity/stability, so I don't think this is a good idea.

Why do think it's not a useful metric? AFAIK, cargo follows semver, and major version 0 indicates that the public API is not stable. I think the Rust ecosystem as a whole would benefit from seeing more maintainers stabilizing their APIs, like the http mainainers recently did. blessed.rs could ever so slightly contribute to that by pointing out the benefit of choosing packages that have moved past the "anything MAY change at any time"-phase.

edited to fix typos.

from blessed-rs.

I also agree that some indicator of stability/maturity would be useful (noting that they're not necessarily the same thing), and also some indication of maintenance status (how actively is the library being maintained). I also agree that version numbers are not a good measure of this. If they were then arguably a separate blessed.rs wouldn't be required.

I think what would probably make sense here is to come up with a custom rating scale (not necessarily numeric) where each rating category has a clear description of it's meaning (so we can have "this is new and experimental", "this is mature and actively maintained", "this is abandoned", "this is mature and in maintenance mode", etc). I think it's potentially a lot of work to rate every crate on the crates list. But I do think this would valuable.

from blessed-rs.