Using pre-release version
xofyarg opened this issue · comments
Hi,
The version is bumped to a pre-release version after each release, which I found is tricky to patch. Here's my use case: I'm currently put domain = "0.10.0" in Cargo.toml, then want to upstream something with a PR. While waiting for the new release, I can drop a patch in Cargo.toml to use my branch. But the source is now on version 0.10.1-dev, so I cannot just simply patch the version from crates-io, as pre-release won't be selected. I have several crates that depends on domain, those will be included in the final binary, so it's cumbersome to update each of them, comparing to set a single patch section in the binary.
I wonder how do you handle the pre-release number in your workflow, any chance to avoid using pre-release ones?
I currently always change the actual dependency to a git dependency (or even a local path) instead of patching. Admittedly, the main reason is that I can’t remember how all this patching works, but it has the advantage that CI and later cargo package catch any accidentally left in change. But I can see how this is annoying if you have to do it in lots of places.
I had a quick lock at some repositories of other projects and it seems people generally leave the version number alone until it is time to release. I suppose we can do that. Not sure if there will be issues after we merge a PR with a breaking change, though?
Not sure if there will be issues after we merge a PR with a breaking change, though?
I guess for people who use crates.io, it doesn't matter. And for those put a git URI, they are safe if they pin to a rev. It will become tricky if they pin to a branch and don't keep Cargo.lock, but I doubt it can be counted as a proper use case.
The risk of bumping to a non-exist version number, is that it can be released by accident, although could be yanked later if noticed. So as you said, lots of people just leave the version number alone, as the current version already exists on crates.io, further attempt to release the same thing will result an error.
The problem I have (if I understand correctly, and apologies if I get anything wrong here as I'm writing this from memory on a phone) with the version number remaining unchanged on main post release is that any commits made to main then cause there to exist two different versions of the application with the same version number.
Any build against main will report itself incorrectly as being the same version as the last release tag.
For example for our Docker images this will mean that the image published from main to the latest tag will report itself as having the same version number as the tagged release version for example.
The approach will be problematic for repositories that produce binary packages for sure. But those are very unlikely to be used as external dependencies, so the current approach should be okay for them.