We do have https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Ais...
It is unclear if there ever will be a Rust 2.0. Even those that want it agree that unless it's incredibly easy to upgrade to from Rust 1.x, it's a non-starter.
It is unclear if there ever will be a Rust 2.0. Even those that want it agree that unless it's incredibly easy to upgrade to from Rust 1.x, it's a non-starter.
We still have some desire to indicate "epochs" of Rust development, as undoubtedly, things like idioms will change over time, new libraries will replace older ones, etc. But I'd prefer something like "modern C++", which could signify this kind of change, without giving up on backwards compatibility.
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.
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.
Python 3 broke Python because it completely changed how strings work. Nothing of that magnitude will ever come to Rust.