Should there be a way to override the version of patched crates?

tools and infrastructure cargo
1

[patch] is super useful when you want to test bug fixes and new features for your library crate, since you can integrate the in-development version into your complex project.

I used to bump the version number of a crate right after releasing a version. For example, if I released 0.3.0, I would bump the version to 0.4.0-dev to mark it as an in-development new version.

The problem with that is that [patch] doesn't work if the version number of the patched crate is different. If you transitively depend on 0.3.0 via other dependencies, they won't use the patched version that's 0.4.0-dev.

So now I'm reluctant to bump the version of a crate until I'm certain I don't want to patch it in for testing anymore.

But maybe there could be a way to override the version of a patched crate, so it advertises itself as 0.3.0, even though its Cargo.toml declares it as 0.4.0-dev.

[patch.crates-io]
mylib.path = "/home/me/projects/mylib"
mylib.version-override = "0.3.0"

Or is it considered the standard practice to not bump your crate version until just before release?

1 Like
2

I can't talk about standard practice, but I'm just noticing that 0.4.0-dev would seem to imply there are breaking changes, and with braking changes patching 0.3.0 might fail anyway. So you could try something like using 0.3.1-dev immediately[1], and upping this to 0.4.0-dev as soon as you've introduced breaking API changes.

If someone does want to integrate a project as a downstream dependency despite breaking changes, then you can probably still do that anyway. For example they could create a local crate that depends on the 0.4.0-dev version and simply re-exports everything, then patch in that re-exporting crate. If something does break then, they'll have to fix it somehow, anyway. Either by editing the using crate (which would then be patched itself and can depend directly on the 0.4.0 version then) or by modifying the wrapping crate (in case the API changes are back-adaptable à la semver-trick), or they could of course clone the -dev version of your crate locally, downgrade the Cargo.toml and locally undo some breaking changes they don't care about.

  1. I'm assuming that would make the [patch] work again, but I haven't tested that ↩︎

2 Likes
3

See allow overriding dependency major version · Issue #5640 · rust-lang/cargo · GitHub

btw this is why I removed post-release version bumps from cargo-release.

3 Likes