Main branch version can prevent Cargo overriding Bevy

[scepea]

Bevy version

0.8.1 / 0.9.0-dev (but would apply to any minor version increment with current release process)

What you did

Attempted to use Cargo's patching feature to override Bevy as a dependency. This was to make use of the recently added ndc_to_world method in Camera.

[dependencies]
bevy = "0.8"
bevy_rapier3d = "0.17.0"

[patch.crates-io]
bevy = { git = "https://github.com/bevyengine/bevy?rev=37860a0" }

What went wrong

Cargo ignores the patch since the minor version is has been incremented by that commit. Cargo only allows dependencies to be overriden where the override's patch number is greater.

Additional information

I fixed this by:

1. Checking out Bevy to the desired commit.
2. Changing the version in cargo.toml to 0.8.2.
3. Using a path override in the patch bevy = { patch = "local/path" }

The initial cargo configuration would patch as expected if the main branch didn't have a higher minor version. Looks like this is done as part of the last release to avoid version confusion in the dev docs (#4230).

I suggest that the release process not increment the minor version number until such a release is imminent. If main currently had a version of 0.8.2-dev then I think this would clear up any dev docs confusion, while still helping users work on the bleeding edge.

So the versioning for this release cycle would be 0.8.2-dev until release day, 0.9.0 for the release, 0.9.1-dev immediately after.

[alice-i-cecile]

This would definitely make your use case of cherrypicking commits easier, but I'm also reluctant to change to e.g. 0.9.1-dev because the semantics are wrong: this would be an alpha version of 0.10, and breaking changes should be expected. What if we used e.g. dev-0.10? Does that play nice with cargo?

[mockersf]

Cargo ignores the patch since the minor version is has been incremented by that commit. Cargo only allows dependencies to be overriden where the override's patch number is greater.

This is actually be design and why Bevy updates after the release to 0.next.0-dev.
Bevy games tend to use a few third party plugins (like bevy_rapier) and they tend to not work well when mixing their released version with Bevy from the main branch. Updating to a semver incompatible version means that for it to work, the plugin also has to provide a version targeting the in-development version.

[alice-i-cecile]

Ah right, I'd forgotten that part of the discussion. I'm going to close this as won't fix for now, but feel free to continue debating here if you feel strongly.

[scepea]

I don't feel strongly enough to argue the point further but do think it's important to document that currently the release process is making it harder to work on the bleeding edge. If that's by design then that's just something we end users have to accept. The workaround is documented for anyone else following the path.

I have noticed that other projects don't tend to change their version number until they're ready to release though. Perhaps as Bevy's API stabilises with future releases this issue should be reconsidered.

[alice-i-cecile]

Makes sense. I'd be happy to review and approve a PR documenting the process here: perhaps in the README?