Can cargo-release recursively bump versions in dependent crates?

[thomaseizinger]

In a big workspace, it is not uncommon for crates to have dependencies upon each other. When one crate appears in another crate's public API, a major bump of the dependency also implies a major bump in the dependent crate.

I think it is out of scope for cargo-release to automatically detect when it needs to recursively bump versions but it would be cool if we could specify in the configuration file, when a version bump should trickle down the dependency chain.

Over at https://github.com/libp2p/rust-libp2p, we are currently trying to automate our release process and correctly bumping the versions is one of those problems that we would like to automate. For example, every crate depends on libp2p-core, so if we make a minor bump in that one (0.x), all other crates needs a minor bump too. What I'd like to have is that the command:

cargo release version --package libp2p-core minor --execute --no-confirm

also bumps the versions of all dependent crates.

I think one cannot necessarily assume that a minor bump also translates to a minor bump so what we would have to configure is, which dependencies are "exposed". This would allow cargo release to make a decision, whether a version bump in crate A translates to a breaking or non-breaking bump in crate B, assuming that B depends on A.

[epage]

#298 is where are we exploring automatic change detection.

This includes a subset of potential ways of moving forward with it, of having configuration for public dependencies. I keep hoping to not implement a bespoke version of public-private dependencies but for us to instead focus on getting the cargo feature implemented.

Going to close in favor of that other issue but I am hesitant to go forward with a bespoke public-private dependency system.

[thomaseizinger]

Thanks for the pointer towards the RFC, agree with your decision.

I'll probably script something on top of cargo-release for our purposes.