That doesn't address my point, which is that you are conflating communication of a thing with the thing itself.
Moreover, it's unclear to me if you're aware that, in the Rust ecosystem, 0.x and 0.(x+1) are treated as semver incompatible releases, while 0.x.y and 0.x.(y+1) are treated as semver compatible releases. While the actual semver specification says "Anything MAY change at any time. The public API SHOULD NOT be considered stable." when the major version is 0, this isn't actually true in the Rust crate ecosystem. For example, if you have `log = "0.4"` in your `Cargo.toml`, then running a `cargo update` will only bump you to semver compatible releases without breaking changes (up to a human's ability to adhere to semver).
Stated more succinctly, in the Rust ecosystem, semver breaking changes are communicated by incrementing the leftmost non-zero version component. In other words, you cannot correctly interpret what version numbers mean in the Cargo crate ecosystem using only the official semver specification. You also need to read the Cargo documentation: https://doc.rust-lang.org/cargo/reference/semver.html#change...
(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.
So I repeat: you are conflating perception with what actually is reality. This isn't to say that perception is meaningless or doesn't matter or isn't a problem in and of itself. But it is distinct from what is actually happening. That is, "the Rust crate ecosystem doesn't use semver version numbers in a way that can be interpreted using only the official semver specification" is a distinct problem from "the Rust crate ecosystem makes a habit of introducing breaking changes on a whim." They are two distinct concerns and you conflating them is extremely confusing and misleading.
When "the thing" is "API stability promises made by the author of a library", then communication of that thing is the thing itself.
I know about the semver exception Rust uses where 0.x is considered a different "major version" to 0.y for the purpose of automatic updates. That's not really relevant. I'm talking about communication between humans, not communication between human and machine. By releasing log 0.4.4 after 0.4.3, you're communicating to the machine that it should be safe to auto-update to the new release, but by keeping the version number 0.x, you're communicating to the human that you still don't promise any kind of API stability.
This is the context of the discussion I'm talking about:
>>> Rust still has a very "Ready to make breaking changes on a whim"
>>> reputation
>>
>> No it doesn't. What on earth are you talking about?
>
> I like Rust, but almost all libraries I end up using are on some 0.x version...
That initial complaint is talking about Rust being ready to "make breaking changes on a whim." But this is factually not true. That is something different from what you perceive the version numbers to mean. Just because several important ecosystem crates are still on 0.x doesn't actually mean that "Ready to make breaking changes on a whim" is a true statement.
> you're communicating to the human that you still don't promise any kind of API stability.
A 1.x version number doesn't communicate that either. Because nothing is stopping someone from releasing 2.x the next day. And so on. Of course, it may usually be the case that a 1.x means the cadence of semver incompatible releases has decreased in frequency. But in the Rust ecosystem, that is also true of 0.x too.
> I'm talking about communication between humans, not communication between human and machine.
Yes, but communication between humans is distinct from describing the Rust as ready to make breaking changes on a whim. You are confusing communication with a description about the actual stability of the Rust ecosystem.
> That initial complaint is talking about Rust being ready to "make breaking changes on a whim." But this is factually not true.
I read the original message as talking about the Rust community broadly, not just the language. You're right that the language itself is pretty stable and doesn't make breaking changes. Regardless, right now, we're clearly talking about the community and libraries, whether that was the original topic or not.
> A 1.x version number doesn't communicate that either. Because nothing is stopping someone from releasing 2.x the next day. And so on.
If a library has been on version 3.x for the past few years, I have some indication that there's some commitment to API stability. If the library recently released version 157.0 and released version 156.0 last week, I have some indication that the library probably doesn't care that much about API stability.
If a library is on version 0.x, it's communicating to me that it's still in an early development phase where they don't care about API stability. It's more like the library where version 157.0 just released than the library which has been on version 3.x for the past few years.
> You're right that the language itself is pretty stable and doesn't make breaking changes. Regardless, right now, we're clearly talking about the community and libraries
No, I know. I am talking about community/libraries too.
> If a library has been on version 3.x for the past few years, I have some indication that there's some commitment to API stability.
As you also do if a library has been on version `0.2` for the past few years. As is the case for `libc`. Or `0.4` for `log`.
Notice that you aren't actually using just the version number. You are making an inference about release cadence to draw a conclusion. Contrast that with the essential communicative role of semantic versioning, which is that it communicates something about the content of the change: whether it's breaking or not. That truly can be read straight from the version number exclusively. But "stability" or "maturity" cannot be.
Moreover, it's unclear to me if you're aware that, in the Rust ecosystem, 0.x and 0.(x+1) are treated as semver incompatible releases, while 0.x.y and 0.x.(y+1) are treated as semver compatible releases. While the actual semver specification says "Anything MAY change at any time. The public API SHOULD NOT be considered stable." when the major version is 0, this isn't actually true in the Rust crate ecosystem. For example, if you have `log = "0.4"` in your `Cargo.toml`, then running a `cargo update` will only bump you to semver compatible releases without breaking changes (up to a human's ability to adhere to semver).
Stated more succinctly, in the Rust ecosystem, semver breaking changes are communicated by incrementing the leftmost non-zero version component. In other words, you cannot correctly interpret what version numbers mean in the Cargo crate ecosystem using only the official semver specification. You also need to read the Cargo documentation: https://doc.rust-lang.org/cargo/reference/semver.html#change...
(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.
So I repeat: you are conflating perception with what actually is reality. This isn't to say that perception is meaningless or doesn't matter or isn't a problem in and of itself. But it is distinct from what is actually happening. That is, "the Rust crate ecosystem doesn't use semver version numbers in a way that can be interpreted using only the official semver specification" is a distinct problem from "the Rust crate ecosystem makes a habit of introducing breaking changes on a whim." They are two distinct concerns and you conflating them is extremely confusing and misleading.