Feedback on `cargo-upgrade` to prepare it for merging

[epage]

@josh

@epage

cargo upgrade replaces cargo update which will be deprecated

Why not the reverse? I don't think there's any cargo upgrade behavior that's fundamentally incompatible with being an option of cargo update.

I was originally going off of your comment about manifest-editing being a default option.

Based on your comments combined with the prior art that Nemo157 brought up, it sounds like the proposal would be summarized as

• cargo update: same as today
• cargo update --save: like cargo update && cargo upgrade --workspace --to-lockfile
• cargo update --incompatible: error if we try to upgrade to an incompatible version, suggesting adding --save
• cargo update --incompatible --save: like cargo upgrade --workspace && cargo update && cargo upgrade --workspace --to-lockfile
• --pinned would still exist but require --incompatible to be present (i.e. we'd start updating pinned version reqs to the lock file)
• Provide the direct dependency summary table at the end

This seems to provide a coherent story though I haven't fully thought through --package / --precises behavior.

Trying to think through different use cases

• There seemed to be general interest in keeping library version requirements low within a major version but to upgrade across major versions. This wouldn't be supported today but if we created a -Z minimal-direct-versions like I've seen ehuss talk about, then that would be a route forward.
• For upgrading individual versions (e.g. cargo upgrade serde), we could always mimic poetry and go get by supporting cargo add <pkg>@latest