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.
> 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`.
If the library has been on 0.2 for a few years, that tells me nothing other than "the developer probably hasn't committed to a stable API yet". It's completely fair for a library on version 0.2.3 to break the API in major ways in version 0.2.4, since it's still in the early development 0.x phase.
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.