Skip to content

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

Closed as not planned
@chriskrycho

Description

@chriskrycho

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).

Note

To be extra clear: This is a reasonable and well-motivated change, and I support it! However, the details of the rollout matter very much.

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!

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions