4 ms·

> 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?

mort96 1y ago
I like Rust, but almost all libraries I end up using are on some 0.x version...
- klardotsh 1y ago
  I find this tends to stem from libraries refusing to declare 1.0 for fear it would lock them into bad decisions, not from being unstable. Chrono is a great example: v0.4 for EIGHT YEARS while they make sure the design and APIs are worthy of being set into stone as 1.0 (think: Stability Bit Versioning). Sure, some pre-1.0 libraries in Rust land are actually wildly volatile, but I find that's not especially the norm, out of the crates I've used. That said... 0.4 for EIGHT YEARS is also a pretty darn good sign you've solidified the API by now, and should probably just tag a 1.0 finally...
  - gldrk 1y ago
    That’s the whole point. Perfectionism and stability are mutually exclusive. What’s ‘worthy of being set in stone’ is very much not set in stone, in an insanely fashion-driven industry like software development.
- baq 1y ago
  Version numbers are bogus anyway. For all you care all those libraries could be YY.MM. Semantic versioning is a lie except for the smallest units.
  - mort96 1y ago
    Version numbers are communication. Version 0.x is the clearest way I can imagine to communicate, "do not expect a stable API".
    - burntsushi 1y ago
      You are conflating what actually _is_ with what you perceive version numbers communicate. The comments above that you are seemingly commenting in support of are talking about "Ready to make breaking changes on a whim," which is factually not true. What you are talking about is some libraries using a version number that you perceive as indicating a lack of stability, even when the actual library is extremely stable (e.g., log and libc). So you seem to be saying "I don't like how Rust libraries communicate their stability." But that's something wholly different from "Ready to make breaking changes on a whim." Yet your commentary doesn't distinguish these concepts and instead conflates them.
      - mort96 1y ago
        Version 0.x communicates, "the API is not stabilized, and you must be prepared for breaking changes on a whim". If a library did not want to communicate that, it would release a version >=1.x. And when most library authors communicate "the API is not stabilized, you must be prepared for breaking changes on a whim", then yeah, of course I am going to perceive that as a lack of stability.
        burntsushi 1y ago
        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-categories 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.

mort96 1y ago

I like Rust, but almost all libraries I end up using are on some 0.x version...

klardotsh 1y ago
I find this tends to stem from libraries refusing to declare 1.0 for fear it would lock them into bad decisions, not from being unstable. Chrono is a great example: v0.4 for EIGHT YEARS while they make sure the design and APIs are worthy of being set into stone as 1.0 (think: Stability Bit Versioning). Sure, some pre-1.0 libraries in Rust land are actually wildly volatile, but I find that's not especially the norm, out of the crates I've used. That said... 0.4 for EIGHT YEARS is also a pretty darn good sign you've solidified the API by now, and should probably just tag a 1.0 finally...
- gldrk 1y ago
  That’s the whole point. Perfectionism and stability are mutually exclusive. What’s ‘worthy of being set in stone’ is very much not set in stone, in an insanely fashion-driven industry like software development.
baq 1y ago
Version numbers are bogus anyway. For all you care all those libraries could be YY.MM. Semantic versioning is a lie except for the smallest units.
- mort96 1y ago
  Version numbers are communication. Version 0.x is the clearest way I can imagine to communicate, "do not expect a stable API".
  - burntsushi 1y ago
    You are conflating what actually _is_ with what you perceive version numbers communicate. The comments above that you are seemingly commenting in support of are talking about "Ready to make breaking changes on a whim," which is factually not true. What you are talking about is some libraries using a version number that you perceive as indicating a lack of stability, even when the actual library is extremely stable (e.g., log and libc). So you seem to be saying "I don't like how Rust libraries communicate their stability." But that's something wholly different from "Ready to make breaking changes on a whim." Yet your commentary doesn't distinguish these concepts and instead conflates them.
    - mort96 1y ago
      Version 0.x communicates, "the API is not stabilized, and you must be prepared for breaking changes on a whim". If a library did not want to communicate that, it would release a version >=1.x. And when most library authors communicate "the API is not stabilized, you must be prepared for breaking changes on a whim", then yeah, of course I am going to perceive that as a lack of stability.
      - burntsushi 1y ago
        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-categories 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.