I apologize if this is a bit of a meta question or if it's been answered before and I haven't found the answer (I have looked), but: how do people generally manage project version numbers in
Cargo.toml in between project releases?
Context for the question: generally I like to use git tags to mark versions of software projects, and derive version numbers from those tags via
git describe. This has the nice benefit that if I'm, say, 3 patches ahead of my last version tag, and I build the project, the resulting version number automatically reflects that (e.g.
By contrast if the version number is in a config file, then either it will be outdated (if e.g. I update the version number to mark a release, and then continue with further development later), or it will be ahead of itself (if e.g. I update the version number as soon as I'm planning a new release, and then add all the changes I want to make in that release). Neither is really a very nice situation to be in.
This isn't rust-specific, obviously, but cargo does seem to require that the
version parameter be set and there is not an obvious way to get it to derive the value from a git tag. So how do people go about managing this parameter when maintaining libraries?
I have come across
cargo-release, and I may well use it, but I'm interested in what people think is the right way to manage the
version parameter independent of any tool, and why. I will say that at first glance I'm not entirely sure I like the idea of
-pre versions (as
cargo-release seems to use) because they seem to me inherently less informative than
Basically I'm looking for strategies, thoughts, best practices, etc. from folks who are more experienced than me at maintaining rust apps and libs, and in particular to learn why people favour one method or another.
Thanks in advance for any advice, and best wishes,