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

[linyihai]

If no one on this, I will take a look

[TheLostLambda]

I don't know if this issue was properly addressed here — the currently nightly means that something like derive-more, on version 1.0.0-beta.7, isn't currently being upgraded to 1.0.0!

I personally pretty strongly feel that this upgrade should be done automatically with the breaking flag?

I think that's was @torhovland was getting at with:

Except maybe if there is a proper release that is higher than the current pre?

Also, in an ideal world, I do feel like it should bump pre-releases if there are several of them — what was the issue with upgrading automatically from 1.0.0-beta.6 to 1.0.0-beta.7? Obviously we shouldn't go from a stable release to a pre-release automatically, but if we're already on a pre-release, I do think we should track it and then automatically upgrade to stable when that's published.

What do others think about that approach?

1. If version is currently stable / non-pre-release, then ignore pre-releases
2. If version is currently a pre-release, upgrade it as normal — including upgrading to the stable version!

[linyihai]

@TheLostLambda Much appreciate your options.

I don't know if this issue was properly addressed here

My PR just prevents pre-release won't downgrade.

What do others think about that approach?

If version is currently stable / non-pre-release, then ignore pre-releases
If version is currently a pre-release, upgrade it as normal — including upgrading to the stable version!

I saw @torhovland had submitted serval PR maybe relevent to your suggestions. If not, I am very pleasure to submit anthor PR to solve this issues.

[TheLostLambda]

Thanks for the swift response!

My PR just prevents pre-release won't downgrade.

That's good to know, that's what it looked like to me too!

I saw @torhovland had submitted serval PR maybe relevent to your suggestions.

And good to know — I'll take a look!

Perhaps we should re-open this issue if it was only partially addressed by your PR?

[Skgland]

I don't know if this issue was properly addressed here — the currently nightly means that something like derive-more, on version 1.0.0-beta.7, isn't currently being upgraded to 1.0.0!

I personally pretty strongly feel that this upgrade should be done automatically with the breaking flag?

I think that's was @torhovland was getting at with:

Except maybe if there is a proper release that is higher than the current pre?

Also, in an ideal world, I do feel like it should bump pre-releases if there are several of them — what was the issue with upgrading automatically from 1.0.0-beta.6 to 1.0.0-beta.7? Obviously we shouldn't go from a stable release to a pre-release automatically, but if we're already on a pre-release, I do think we should track it and then automatically upgrade to stable when that's published.

What do others think about that approach?

1. If version is currently stable / non-pre-release, then ignore pre-releases
2. If version is currently a pre-release, upgrade it as normal — including upgrading to the stable version!

Isn't this what was pointed out in #14250 (comment) and is listed in the last checkbox in #12425 (comment)

[TheLostLambda]

@Skgland That's a good eye! Sorry for missing those!

The first one, #14250 (comment), seems to correctly point out that the first two of those tests are "unsolved" things that we'd like to support, and I agree we should support them!

The second link, the last checkbox in #12425 (comment) I think matches my suggestion! These both I think are good ideas:

• 2.0.0-beta.1 to 2.0.0-beta.2
• 2.0.0-beta.1 to 2.0.0

Though I, like the author, am less sold on:

• I am not sure about if 2.0.0-beta.1 to 3.0.0-beta.1 should works

Perhaps that's better as 2.0.0-beta.1 to 3.0.0? That way you have to opt into each pre-release series, but you never "skip over" a chance to return to stable!

EDIT: Either way, I think this issue should be reopened? Or some new issue made to track that last checkbox!
EDIT2: I'm bad at reading! I misinterpreted the first link you sent! That's my bad!

[epage]

@TheLostLambda for the problem that was reported in this Issue, it has been resolved (just because it has prerelease in the title does not mean ti covers every prerelease case). This should not be re-opened. If there is another problem with the behavior, open an issue for it.