Implicit install breakage falls below usual project standards

Hi folks, I just learned about the breaking change in https://github.com/rust-lang/rustup/pull/3985 as it was released today. I can understand why this change might be desirable, but I have concerns that the change was released without the kind of messaging or feedback mechanism that Rust users have come to expect from the project.

Rustup is an incredibly useful and valuable tool for Rust, forming the entry point of the vast majority of users' experience with Rust. Of course, that kind of importance means we must be careful. The kind of experience that Rust tries to prevent with its stability guarantee is "this used to work and it doesn't anymore". Each of these is frustrating to users and they are usually experienced "in anger". Each time we create them, we are taking out a loan against Rust's reputation with the expectation that Rust will get significantly better as a result of the change.

I do see that there was care to add an error message prompting the user with the exact command to run - that is in line with what users expect from Rust, and is highly appreciated. At the same time, there were two steps not taken that I have considered standard for any breaking change on the lang team:

• A final comment period run with @rfcbot that indicates a supermajority of the team is on board with the change. This gets published in places like This Week in Rust, giving users the opportunity to voice their opinion and team members to raise an objection on their behalf.
• For any change with significant disruption (i.e. any nontrivial number of broken crates in crater), starting with a future compatibility warning that gives users time to update ahead of the breaking change.

Additionally, some changes are accompanied with a dedicated blog post ahead of the change explaining the rationale for the change with instructions to users. Going through this process is more work, but I would argue it is not worth making a disruptive change without taking these steps.

Finally, I suspect this situation is arising because we don't have a project-wide standard for how breaking changes are handled. I have seen a need for this in other recent situations too; this just happens to be the one I'm commenting on. In parallel with this conversation, I would ask @rust-lang/leadership-council to adopt such a standard – even a basic one we can iterate on is better than none. I think it rises to the level of the leadership council because of the reputational risk each breaking change creates for Rust, and we should not expect individual teams to have to decide for themselves how to navigate that risk without guidance.

Start by reviewing rustup#3985 and this issue's discussion, then examine the proposed roles for rfcbot, crater, This Week in Rust, blog posts, and the leadership council. Define what a project-wide breaking-change standard should require and where it should be documented; done means the standard is agreed on and adopted.