Reoccurring bevy_dylib issue with Cargo when Bevy updates to a new major 0.x version

[Steveplays28]

This issue seems to be reoccurring with every major 0.x Bevy update: #14585
It gets fixed for me by running cargo info bevy_dylib on Fedora 44, but it's a small annoyance.
cargo update and cargo update bevy have no effect.

Is this reported somewhere on Cargo's issue tracker?
I can't find much about it myself except for the linked GitHub issue above and this discussion: #20201.

[cookesan]

I would split this into Bevy state and Cargo state.

On the Bevy side, bevy_dylib is the dynamic-linking support crate. The dynamic_linking feature pulls in dep:bevy_dylib, and the dependency is versioned alongside Bevy. The recommended path in the crate docs is:

cargo run --features bevy/dynamic_linking

The manual direct-dependency path also exists, but then bevy_dylib has to track the Bevy version you are using.

If running cargo info bevy_dylib fixes the next build without you changing Cargo.toml, that points away from Bevy source and toward local Cargo registry/index/cache state. cargo info is a package-information command; it fetches package metadata. It should not be a Bevy-specific build step.

For a useful Cargo report, I would include:

Cargo version
registry protocol/config if customized
before/after Cargo.toml and Cargo.lock
failing cargo build -vv output
same build succeeding after only running cargo info bevy_dylib
whether Cargo.lock changes between the failing and passing runs

If Cargo.lock is pinning an old bevy_dylib, update the lockfile normally. If the lockfile does not change and only cargo info bevy_dylib changes the outcome, that is the strongest case for reporting it to Cargo with a minimal reproduction.