No, that's only how the software resolution works.
That is actually true, but not many follow the guidelines or seem aware of them. The Cargo Book states that it follows SemVer, which in turns explicitly says:
Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.
If you look at the icons on crates.io, you'll also see they're shown in a warning orange colour when not yet at version 1.
Beyond version 1, there's the pre-release "alpha" and "beta" suffix to signal unstable versions, which is sometimes used but not often.
It's not too late to change: all it takes is for the crates to update their version when they have the chance. More importantly, I think it's not too late for the future crates to follow that pattern. We all know that not everything falls into place immediately. 
And, of course, nothing beats checking at the issues and activity in the repository itself to get a better idea, but still.
Anyway, sorry for the off-topic excursion.
My impression is that it is more that the 0.x.y is so common in heavily used, heavily tested, i.e., "stable", Rust crates, that we've started to ignore the fact that they're not 1.0 yet. It's unfortunate.
2 Likes
Re: typescript union: fundamentally this is a bit weird as a type, it's both definitely an integer but also you can't eg add two valid MyLimitedOptionsType values and get another back (in typescript I believe that would be just number). If you don't need to add or the like, why are they numbers? If they are from input data and each value is a specific meaning, just mapping to normal enum variant is clear and easy.
The general solution is a newtype wrapper, and despite being potentially a lot of work it's quite helpful to go through so you understand what you're actually after. Having an explicit type is often quite handy anyway, as it means you can directly attach helper methods directly to it!
Re: versions: this is a common issue with the JS world too, possibly semver in general. Node got to 0.12 until that whole io.js (Jesus, that was 10 years ago already?) thing kicked it into 4.0, React infamously had essentially won UI well before they decided it was pretty silly they were still 0.14 and jumped directly to 15.0.
It's possible there's lots of popular projects in other ecosystems that also have the same issue, since it seems to arise from a pretty generic cause: you are figuring things out and getting feedback on what's working, but just when you find it's actually all good, you have a bunch of people depending on you. There right fix here seems like a change to semver itself, or at least how tools use it, so that you can go from a "unstable v1 API" to a "stabilized v1 API" without that being a breaking change (going back would be, of course). Perhaps as simple as adding a prerelease label by default?
3 Likes
SemVer is not exclusive to Rust's crates; there's a whole ecosystem out there, and people are used to that numbering. Personally, I'm very reluctant to use a crate which is 0.x (but still cautious when it's not). And it's quite intuitive: 0.x means it's still experimental—otherwise, how would you know?
The "Sem" in SemVer is for "Semantic", which you really don't want to change because it's common ground. Many people confuse "it's" for "its", but that's not a good reason to change the grammar. 