`cargo update --breaking` doesn't work like `cargo upgrade -i`

[VorpalBlade]

Problem

I was led to believe that cargo +nightly -Zunstable-options update --breaking should be a drop-in replacement for cargo upgrade -i. But it isn't. Specifically it doesn't seem to upgrade Cargo.toml unless there is a breaking change.

I use cargo upgrade to upgrade to new minor versions in Cargo.toml too. There are several reasons for this:

• As I'm on the latest version when developing, I can't be sure I'm not relying on some new API that didn't exist in the version that is declared in Cargo.toml. While I believe there is some "min-version" flag to test with, I prefer to just force everything the latest. (No I don't care about LTS distros like Debian etc, not one bit, nor about people who are not on the most recent stable Rust. My MSRV is N.)
• If there are any security issues in a dependency I'd also prefer to force the latest version there too.

Steps

1. cargo +nightly -Zunstable-options update --breaking
2. Notice that nothing is listed as changed
3. cargo upgrade
4. Notice how it updates dependencies in Cargo.toml as well.

Possible Solution(s)

Possibly some people want this behaviour? So maybe add yet another flag to toggle that?

Notes

The behaviour described above can be observed on https://github.com/VorpalBlade/paketkoll (revision 0747756e401d304748c7d98c432df35eef44ac97) if you need to test it out.

Version

❯ cargo version --verbose
cargo 1.79.0 (ffa9cf99a 2024-06-03)
release: 1.79.0
commit-hash: ffa9cf99a594e59032757403d4c780b46dc2c43a
commit-date: 2024-06-03
host: x86_64-unknown-linux-gnu
libgit2: 1.7.2 (sys:0.18.3 vendored)
libcurl: 8.6.0-DEV (sys:0.4.72+curl-8.6.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Arch Linux Rolling Release [64-bit]

❯ cargo +nightly version --verbose
cargo 1.81.0-nightly (a515d4634 2024-07-02)
release: 1.81.0-nightly
commit-hash: a515d463427b3912ec0365d106791f88c1c14e1b
commit-date: 2024-07-02
host: x86_64-unknown-linux-gnu
libgit2: 1.8.1 (sys:0.19.0 vendored)
libcurl: 8.8.0-DEV (sys:0.4.73+curl-8.8.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Arch Linux Rolling Release [64-bit]

[epage]

cargo update --breaking is not a direct replacement for cargo upgrade -i. When designing how update of breaking changes can be integrated into cargo update, we viewed --breaking as a "force" flag that will cause the requirements to change that are needed to make the update go forward.

The design was specified in #12425 (comment) and #12425 is in general the issue for this level of design discussion.

Closing in favor of #12425. If there is a reason for us to keep this open separately, let us know!

[VorpalBlade]

So there is no plan to make this a replacement? I believe this is the feedback you wanted in killercup/cargo-edit#869

And in it's current form I see cargo update --breaking as fairly useless.

Do you want me to copy my misgivings about it across to the tracking issue as well?

[epage]

As i said, the linked issue is responsible for the design and feedback should be given there. We tried to socialize this through the Internals design thread, fcp, etc to ensure timely feedback before implementation. We are close to having a full implementation and planned to do Call for Testing to get more direct feedback.

In commenting on the design, I'd recommend first read the two comments of mine at the top of the issue and tailor your feedback with those comments in mind.