`cargo update --breaking` doesn't respect pre release

[thewh1teagle]

Problem

Hello!
I use cargo update from nightly release to upgrade dependencies
However looks like cargo doesn't respect beta semver:

cargo +nightly -Zunstable-options update --breaking
    Updating crates.io index
   Upgrading env_logger ^0.10.1 -> ^0.11.3
   Upgrading tauri ^2.0.0-beta.21 -> ^1.7.0
   Upgrading tauri-plugin-deep-link ^2.0.0-beta.5 -> ^0.1.2
   Upgrading windows ^0.56.0 -> ^0.57.0
   Upgrading reqwest ^0.11.23 -> ^0.12.5
    Updating crates.io index
error: failed to select a version for `webkit2gtk-sys`.

Notice the line

 Upgrading tauri ^2.0.0-beta.21 -> ^1.7.0

Steps

1. Install tauri beta release
2. upgrade it

cd /tmp
cargo init --bin sample
cd sample
cargo add tauri@=2.0.0-beta.22
cargo +nightly -Zunstable-options update --breaking

Then compare with https://crates.io/crates/tauri/versions

Possible Solution(s)

Respect beta versions

Notes

Also, I wanted to say that I'm really looking forward to seeing this feature, as I'm using cargo upgrade from cargo-edit, which takes tremendous time to upgrade dependencies, while cargo update from nightly does the same job much quicker.

Version

$ cargo -Vv
cargo 1.75.0 (1d8b05cdd 2023-11-20)
release: 1.75.0
commit-hash: 1d8b05cdd1287c64467306cf3ca2c8ac60c11eb0
commit-date: 2023-11-20
host: aarch64-apple-darwin
libgit2: 1.7.1 (sys:0.18.1 vendored)
libcurl: 8.6.0 (sys:0.4.68+curl-8.4.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 1.1.1u  30 May 2023
os: Mac OS 14.5.0 [64-bit]

$ cargo +nightly -Vv                                 
cargo 1.81.0-nightly (4ed7bee47 2024-06-25)
release: 1.81.0-nightly
commit-hash: 4ed7bee47f7dd4416b36fada1909e9a62c546246
commit-date: 2024-06-25
host: aarch64-apple-darwin
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.6.0 (sys:0.4.72+curl-8.6.0 system ssl:(SecureTransport) LibreSSL/3.3.6)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Mac OS 14.5.0 [64-bit]

[weihanglo]

I don't think Cargo allows upgrade pre-release versions at this moment. You may need to specify each crate separately with the --precise flag. See the relevant doc.

That said, maybe at this moment before figuring out the correct SemVer for pre-releases, --breaking should not touch nor upgrade any of them.

cc @torhovland

[torhovland]

Yes, it looks like we should not try to upgrade (or downgrade) dependencies that are currently on a pre-release. Except maybe if there is a proper release that is higher than the current pre?

@epage Thoughts?

I will be away for a few weeks now, so if anybody wants to tackle this, feel free.

Nice to see that we are faster than cargo-edit 🎉

[epage]

Yes,

• We shouldn't downgrade. I beta yanked would do the same
• Prerelease version reqs should be treated like any other version req for --breaking

[epage]

Also, being faster is easy; cargo-edit does not use the sparse registry.

[weihanglo]

added to #12425 (comment).