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

Most upvoted comments

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-version flag but this is not the default and most don’t use it.

This result is that for the majority of repositories using cargo-release, master is on a new dev version which means that PR’s cannot be tested with cargo patch.

So in it’s default configuration, cargo-release makes collaboration more cumbersome.