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.