The versioning issue is that as Rustfmt evolves, the formatting will change and thus by running rustup update, we might move from passing to failing on CI. This is bad, it would be better to have the user opt-in to the version changing. We also need it to be easy for a contributor to run the exact same version of Rustfmt as is run on the CI. However, this is complicated by the Rustup distribution model: the version of Rustfmt is tied to the toolchain used by Rustfmt.

One step towards fixing this is to specify the Rustfmt version in the rustfmt.toml. Then emit a specific error if the versions don't match. This doesn't solve the problem, but it does make the problem explicit, rather than being a confusing, hard to fix error. This might be sufficient for 1.0, together with a strict channel system to ensure that formatting changes rarely.

Versioning issue can be solved by cargo install --version, though it would be nice if rustup does have the similar functionality. Also cargo install is much slower than rustup component add.

Ideally we'd have a solution that worked for Rustup without having to rebuild from source. Though it might be that we just have to accept building from source (the problem of course being if the user is on a stable toolchain because we use unstable features).

On Rustup, it is difficult because we're closely tied to the compiler version (although not too closely, nowadays).

Perhaps we could have a story including only the diffs (and using rustfmt-format-diff). Apparently this is the Chrome/clang-format strategy.

Versioning is discussed in rust-lang/rfcs#2437

RFC 2437 is in FCP, so I believe this issue is complete (we still need to implement versioning, but that can come later).