cargo-edit icon indicating copy to clipboard operation
cargo-edit copied to clipboard

set-version: Add option to *not* change dependencies of other crates in workspace

Open opara-tor opened this issue 2 months ago • 2 comments

When you run cargo set-version --bump minor -p foo in a workspace that has crates "foo" and "bar", and "bar" has a dependency of "foo", the Cargo.toml for "bar" will also be updated to bump the version of "foo". It would look something like:

   Upgrading foo from 1.6.0 to 1.7.0
    Updating bar's dependency from 1.6.0 to 1.7.0

This is okay as a default, but sometimes you might not want to update "bar"s dependencies. For example say that "foo" gained a new feature (hence the minor version bump), but "bar" doesn't use the feature and works fine with "foo" 1.6.0. By increasing "bar"s dependency version, it forces all users of "bar" to upgrade their version of "foo" even though it's unnecessary.

In a workspace with only two crates this is easy to work around (just git stage the specific changes you want), but in a workspace with many crates and many version bumps (and which may be automated with a script), this can be a bit painful.

It would be nice if there was a flag where you could disable this feature. (I also tried cargo set-version --bump minor -p foo --exclude bar, but that didn't seem to help.)

opara-tor avatar Oct 28 '25 23:10 opara-tor

cargo-set-version was pulled out of cargo-release which has

      --dependent-version <ACTION>   Specify how workspace dependencies on this crate should be handed [possible
                                     values: upgrade, fix]

I didn't include that in cargo-set-version because I wasn't thrilled with the name, wanted to be cautious about whats included for a simpler path to merging this into Cargo if people requested it (no one has), and its a flag that is easy to get wrong. I went with the "safe" option as the built-in behavior.

epage avatar Oct 29 '25 13:10 epage

Okay thanks! I'll leave this open then just to see if anyone else has interest in it. (Or feel free to close if you don't think this is suitable for this project.)

I don't have any suggestions for a better name, but can think on it more if there's ever further interest in it.

opara-tor avatar Nov 11 '25 17:11 opara-tor