Do not call it "Downgrading" when difference is only build metadata

[dtolnay]

What does this PR try to resolve?

When a cargo update --precise changes a dependency between 2 versions which differ only in build metadata, Cargo prints a log referring to it as "Updating" or "Downgrading" the dependency, depending on a comparison between the build metadatas.

This is usually not meaningful, given that build metadata is often stuff like git commit hashes, which are not meaningfully ordered.

    Updating crates.io index
 Downgrading foo v0.0.1+43ef4fe -> v0.0.1+2c65d16
    Updating bar v0.0.2+bc17664 -> v0.0.2+c144a98

This PR changes to the word "Switching" when the version major, minor, patch, and pre-release value are not being changed.
This PR uses the word "Updating" when the version major, minor, patch, and pre-release value are unchanged, regardless of whether the build metadata is going up or down.

How should we test and review this PR?

• cargo test
• cargo build --release
• /path/to/cargo/target/release/cargo add tonic_datastore_v1
• /path/to/cargo/target/release/cargo update -p tonic_datastore_v1 --precise 0.1.0+3562b6cb3
• /path/to/cargo/target/release/cargo update -p tonic_datastore_v1 --precise 0.1.0+ee9e8e4e6

Before:

After:

After:

[rustbot]

r? @epage

(rustbot has picked a reviewer for you, use r? to override)

[epage]

What I'm wondering is if this is worth defining the semantics for seeing as

• We document that this shouldn't be happening (docs)
• The bug that allowed it on crates.io has been fixed (Prevent similar versions that only differ in build metadata from being published crates.io#6518)

[dtolnay]

The documentation is that you shouldn't publish two versions that differ only in build metadata, but this case can arise locally without publishing. A path dependency or git dependency might change build metadata without the previous build metadata ever being published. cargo update prints its "Updating" / "Downgrading" message in this case.

[dtolnay]

custom_target::changing_spec_relearns_crate_types failure on "Windows x86_64 gnu nightly" appears unrelated: "linking with `rust-lld` failed: exit code: 0xc0000374".

---- custom_target::changing_spec_relearns_crate_types stdout ----
running `D:\a\cargo\cargo\target\debug\cargo.exe build --lib --target custom-target.json -v`
running `D:\a\cargo\cargo\target\debug\cargo.exe build --lib --target custom-target.json -v`
thread 'custom_target::changing_spec_relearns_crate_types' panicked at tests\testsuite\custom_target.rs:218:10:

test failed running `D:\a\cargo\cargo\target\debug\cargo.exe build --lib --target custom-target.json -v`
error: process exited with code 101 (expected 0)
--- stdout

--- stderr
   Compiling foo v0.1.0 (D:\a\cargo\cargo\target\tmp\cit\t1117\foo)
     Running `rustc --crate-name foo src\lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type cdylib --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C metadata=987467f931cbf061 --out-dir D:\a\cargo\cargo\target\tmp\cit\t1117\foo\target\custom-target\debug\deps --target \\?\D:\a\cargo\cargo\target\tmp\cit\t1117\foo\custom-target.json -L dependency=D:\a\cargo\cargo\target\tmp\cit\t1117\foo\target\custom-target\debug\deps -L dependency=D:\a\cargo\cargo\target\tmp\cit\t1117\foo\target\debug\deps`
error: linking with `rust-lld` failed: exit code: 0xc0000374
  |
  = note: "rust-lld" "-flavor" "gnu" "--version-script=C:\\Users\\RUNNER~1\\AppData\\Local\\Temp\\rustcwHhD0U\\list" "--no-undefined-version" "D:\\a\\cargo\\cargo\\target\\tmp\\cit\\t1117\\foo\\target\\custom-target\\debug\\deps\\foo.foo.22cab9f376391196-cgu.0.rcgu.o" "--as-needed" "-L" "D:\\a\\cargo\\cargo\\target\\tmp\\cit\\t1117\\foo\\target\\custom-target\\debug\\deps" "-L" "D:\\a\\cargo\\cargo\\target\\tmp\\cit\\t1117\\foo\\target\\debug\\deps" "-L" "C:\\Users\\runneradmin\\.rustup\\toolchains\\nightly-x86_64-pc-windows-gnu\\lib\\rustlib\\custom-target\\lib" "-Bdynamic" "--eh-frame-hdr" "-z" "noexecstack" "-L" "C:\\Users\\runneradmin\\.rustup\\toolchains\\nightly-x86_64-pc-windows-gnu\\lib\\rustlib\\custom-target\\lib" "-o" "D:\\a\\cargo\\cargo\\target\\tmp\\cit\\t1117\\foo\\target\\custom-target\\debug\\deps\\libfoo.so" "--gc-sections" "-shared"
  = note: 

error: could not compile `foo` (lib) due to previous error

Caused by:
  process didn't exit successfully: `rustc --crate-name foo src\lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type cdylib --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C metadata=987467f931cbf061 --out-dir D:\a\cargo\cargo\target\tmp\cit\t1117\foo\target\custom-target\debug\deps --target \\?\D:\a\cargo\cargo\target\tmp\cit\t1117\foo\custom-target.json -L dependency=D:\a\cargo\cargo\target\tmp\cit\t1117\foo\target\custom-target\debug\deps -L dependency=D:\a\cargo\cargo\target\tmp\cit\t1117\foo\target\debug\deps` (exit code: 1)

failures:
    custom_target::changing_spec_relearns_crate_types

[epage]

Thanks for your patience in applying the feedback and not just addressing this but stopping the bleed of "yet one more place we do this" and going beyond that, looking to the bigger picture of what the API should be for semver

@bors r+

[bors]

📌 Commit f1d2237 has been approved by epage

It is now in the queue for this repository.

[bors]

⌛ Testing commit f1d2237 with merge 90fb62f...

[bors]

☀️ Test successful - checks-actions
Approved by: epage
Pushing 90fb62f to master...