Breaking change in 1.28: consider yanking and releasing as 2.0? #4210

The API of a command line tool like rustup—particularly one that like rustup does not publish a programming API—just is its command line interface. The 1.28 release changed the behavior of rustup <command> not to install the relevant toolchain (#3985).

This is a breaking change, and as such should not be rolled out as part of a minor release, where it is likely going to cause a non-trivial amount of churn as people work to update it.

I strongly suggest the following course of action:

1. Yank 1.28.0.

2. Revert the change.

3. Publish the reversion as 1.28.1.

4. If you are indeed committed to publishing this and doing so urgently, go ahead and do so as a new 2.0 release. If you don’t want to do a 2.0 release, that’s perfectly fine, but you should then not release this breaking change.

Bonus: I would strongly suggest finding a mechanic for getting more feedback on this kind of change before rolling it out in the future. I’m pretty plugged into the Rust community and ecosystem, and I had no idea this was even being considered, and if I had, I would have noted that it was (a) a good idea in many ways but also (b) needed to be a breaking release, with the concomittant considerations of “do we want to do a breaking release?” and “do we want to do a breaking release now?” that would naturally entail.

Rust’s commitment to stability and clear use of SemVer should absolutely apply to its core tools as well!