Use Cargo workspace features for internal dependency versions #16652
Comments
viridia
added
A-Cross-Cutting
|
I like this idea. This doesn't have the same issues that specifying external dependencies at a workspace-level does. |
|
this is not a pain point as its handled by scripts and it already "just works" |
|
Workspace dependencies were broken when used with our compilation tests, last I checked, since they are technically in another workspace. If you get it working, though, I'm all for this!
I think there's serious benefit in trying to make our codebase the best it can possibly can be, because it shows that we care about our work. Yes, there are people whose expertise mean that their time is better spent elsewhere, but there are also new, unfamiliar faces who can easily tackle this without needing to learn months of knowledge. We can't achieve perfection, but there's virtue in trying to be improve, step by step. |
TimJentzsch
added
the
S-Ready-For-Implementation
Currently all of the Bevy sub-packages which depend on other parts of Bevy use explicit version numbers. This means that whenever a version of a package is bumped, you have to change the version number in every Cargo.toml that references it.
It would be much less work to use Cargo's workspace versioning feature:
This will use the version number specified in the top-level Cargo.toml (in the section
workspace.dependencies).Doing this means that the package version for each crate only needs to be specified in two places: in the package itself, and in the top-level
workspace.dependencies. This will making bumping the versions much easier.The text was updated successfully, but these errors were encountered: