-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: single source of truth for crate versions #2075
Comments
For code at least cargo will pass the version as an environment variable (accessible via |
For simple one crate binaries clap-rs reads the aforementioned env variable w/ crate_version! macro, and could be added to docopt and getopts. |
With the new workspaces feature this is becoming a bit more relevant now I think. We just set up a larger Rust project into many independent sub crates which we want to release together. Right now I'm planning on making a script that bumps all versions in one go but not having to do that would be great. |
With rust-lang/rfcs#2906 Workspace [workspace]
version = "1.2.3" Crate [package]
name = "foo"
version.workspace = true
rust-lang/rfcs#2906 provides a solution for this but it is a breaking change so in #8415 we are proposing to drop it. Using something like
I'd recommend checking out https://github.com/baoyachi/shadow-rs or https://github.com/rustyhorde/vergen |
Since this is a quite old issue, I am going to close it. Cargo's workspace inheritance should help with that in most use cases. For other feature requests and alternatives, read Ed's comment #2075 (comment). If you want to integrate |
Often you need to specify the crate version in several places:
Additionally, you sometimes have several crates within the same repository, whose versions you want to keep in lock-step. The crate version must then additionally be specified:
For more complex projects, it's easy to imagine that there's other information which may be desirable, eg. git commit hash, build date, and additional configuration options (think rust's channel system).
All in all, this can make publishing a new version somewhat tedious and error-prone. Honestly I don't know what a good and general solution is that covers all of these cases.
Currently the only way I can see of doing it would be to turn most of the project into template files which are passed through a pre-processor by the build script, but this is extremely intrusive, and wouldn't work for redundancy within Cargo.toml itself.
The text was updated successfully, but these errors were encountered: