cargo-release: Pre-release versioning incompatible with [patch]
Hey there,
I’m not sure whether this is strictly an issue, but it took me some time to work out and seems like a bit of a pain.
When cargo release X is run the version is bumped, the crate is published, then the version is again bumped to a development version. As cargo expects patch versions to match, this final bump means that you can no longer use [patch] overrides against the currently published library version for testing (without reverting the crate version in the patched crate’s Cargo.toml).
This results in errors like:
warning: Patch `rr-mux v0.4.1-alpha.0 (/home/ryan/projects/rr-mux)` was not used in the crate graph.
Where the project cargo.toml contains:
[dependencies]
rr-mux = "0.4.0"
...
[patch.crates-io]
rr-mux = { path = "../rr-mux" }
One fix is to always run cargo release with --no-dev-version to avoid the problem.
My suggestion would be that that the second development version bump should be opt in, I didn’t expect it to happen, but, either way there’s now some documentation for anyone else who has the same problem.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 3
- Comments: 16
Commits related to this issue
- fix(config)!: Disable dev-version by default Having a post-release version bump can help communicate that someone is using `main` but has the problems of - It isn't actually the next version because ... — committed to epage/cargo-release by epage 3 years ago
- fix(config)!: Disable dev-version by default Having a post-release version bump can help communicate that someone is using `main` but has the problems of - It isn't actually the next version because ... — committed to epage/cargo-release by epage 3 years ago
We’ve now released v0.18.0 with dev-version disabled by default.
Thank you all for your patience in explaining the impact and scope of this problem!
I’ve come up against this again.
I know there is the
--no-dev-versionflag but this is not the default and most don’t use it.This result is that for the majority of repositories using
cargo-release,masteris on a new dev version which means that PR’s cannot be tested with cargo patch.So in it’s default configuration,
cargo-releasemakes collaboration more cumbersome.