-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
use workspace inheritance for common version #8925
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to see the same thing being done for dependencies too (both so we get a better overview of all external dependencies and avoid duplicate versions) but that can be a separate PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you also update the release docs to mention that the version should be bumped in ./Cargo.toml
now rather than ./VERSION
?
Lines 12 to 13 in b7f98d1
* Edit the `VERSION` file and change the date to the next planned release | |
* Releases are planned to happen every two months, so `22.05` would change to `22.07` |
The sub-bullet there could also probably use a bit of rewording, something like: "Releases are planned to happen every few months as time allows. Versions follow CalVer so a release in May of 2022 would be 22.05.0
" (Since we'd like to experiment with smaller releases around 1mo and sometimes end up with larger releases more than 3mo.)
3fdf957
to
8990f4e
Compare
8990f4e
to
1fc4105
Compare
1fc4105
to
e8b9438
Compare
Ok this was changed to still use the |
By using the top-level
Cargo.toml
and workspace inheritance, we can eliminate all the duplication of the version number, and makecargo build
report the correct version (rather than the old 0.6.0). This does require adding a patch version to make it semver compatible.