6 ms·

I sort of want to make an RfC for 2.0 preparation. I am mostly on team "never 2.0", but I recognize that I am sadly not overlord of all things Rust (if I were w

I sort of want to make an RfC for 2.0 preparation. I am mostly on team "never 2.0", but I recognize that I am sadly not overlord of all things Rust (if I were we'd have stable emoji identifiers already) and it's quite possible that 2.0 will happen some day. The idea is to come up with a set of processes for 2.0. If the community decides to do a breaking 2.0 for some reason, we should: - Document exactly what has changed. - Write extensive docs on upgrading - Write good tools that do the upgrade for you when possible, and point out areas where they can't help with links to docs. - Make it so that the cases where stuff isn't machine-upgradeable are minimal - Be wary of actually removing deprecated APIs. - Be wary of unnecessary extra breakage. Python 3 took the attitude of "Okay, we're going to be breaking some things anyway, so let's break more!". I think that they had good reasons for doing that; and it makes sense in a way. But we may not want to follow the same philosophy.

CryZe 10y ago
I feel like you could just add a version number to the Cargo.toml (cargo new would automatically set the latest one). The crate would then be built with the semantics of that version and all crates you use still use the version they were designed for (as long as the semantics can be properly translated between the individual versions).
- Manishearth 10y ago
  That wouldn't work in practice. Breaking changes need not be syntactic, and probably wouldn't be syntactic -- Rust isn't going to break the language for that. There's a good chance it would be semantic breakage that can't allow interoperation between crates.
  - comex 10y ago
    What sort of semantic breakage do you have in mind? My impression is that there are few changes of that sort that couldn't be worked around somehow.
    - Manishearth 10y ago
      Changes to the orphan rules, for one. Changing the behavior and representation of stdlib APIs. You would end up with e.g. two incompatible representations of String being used across the crate boundary.

CryZe 10y ago

I feel like you could just add a version number to the Cargo.toml (cargo new would automatically set the latest one). The crate would then be built with the semantics of that version and all crates you use still use the version they were designed for (as long as the semantics can be properly translated between the individual versions).

Manishearth 10y ago
That wouldn't work in practice. Breaking changes need not be syntactic, and probably wouldn't be syntactic -- Rust isn't going to break the language for that. There's a good chance it would be semantic breakage that can't allow interoperation between crates.
- comex 10y ago
  What sort of semantic breakage do you have in mind? My impression is that there are few changes of that sort that couldn't be worked around somehow.
  - Manishearth 10y ago
    Changes to the orphan rules, for one. Changing the behavior and representation of stdlib APIs. You would end up with e.g. two incompatible representations of String being used across the crate boundary.