Optionally have set-version update Cargo.lock

[mmun]

It would be useful in CI / automated publishing scenarios to have cargo set-version ... optionally (e.g. with a flag) able to bump the version in Cargo.lock.

Currently we're relying on subsequent commands (e.g. cargo check) in our workflow to bump the version in Cargo.lock, but this means that we can't run these commands with --locked.

[epage]

Yes,. for all of cargo-edit this is something I've thought of from time to time. The big issue in cargo-edit is the testing. The test infrastructure within cargo is much better and able to handle it, we just haven't implemented it yet for cargo add.

A big question I've had is how all of this should interact with the global. args --frozen and --locked

[mmun]

Yeah, that makes sense.

I think that in the scenario where you're only interested in changing the crate's own version it would be beneficial to treat all the other crate dependencies as locked.

Specifically, I'm thinking about this scenario:

• You have a Cargo.lock that has stale crate dependencies (i.e. it would be modified if you ran cargo build)
• You try to bump the version with the hypothetical new command cargo set-version 2.0.0 --update-lockfile

This scenario should either fail or just update the version in both Cargo.toml/Cargo.lock, but it shouldn't also attempt to bump the stale crate dependencies versions in the Cargo.lock.

On the other hand, with cargo add/rm it seems like it would make sense to use the full procedure Cargo uses to update a Cargo.lock.

tl;dr: I think there is some value in differentiating how Cargo.lock is updated between cargo set-version and cargo add/rm.

[sfackler]

It would also be nice to have this option in cargo upgrade.