Fix MSRVs for standalone crates

[BenjaminBrienen]

Objective

MSRV in the standalone crates should be accurate

Solution

Determine the msrv of each crate and set it

Testing

Adding better msrv checks to the CI is a next-step.

[mockersf]

I think most of those changes are not justified outside of "you think it looks better"

I would prefer to not change the version of dependencies, even for something compatible, without a need to change it for that dependency. Even worse to do it for everything at once.

For MSRV, adding it to most crates will just make it more painful for us to maintain: for the crates that can't be used outside of Bevy, adding it doesn't bring us any value and will just need more work.

[BenjaminBrienen]

[BenjaminBrienen]

To address the other feedback:

• I do think it looks better. The alternative options that feel "correct" to me would be:

  • keeping the version numbers in-line with what versions are actually being used, which is incredibly noisy and unnecessary
  • using something similar to cargo msrv for dependencies to see which minor version is actually necessary for compilation, which sounds way too complex for 0 value.

• I have ensured that no dependencies have been downgraded or updated by diffing Cargo.lock.

• I have made sure that the rust-version is only specified for public crates. The maintenance cost will be hopefully the exact same as it is now or even less after I have finished improving the CI. We can make it so that the developer doesn't have to edit the value themselves, even. The bot can do that.

[mockersf]

• I do think it looks better.

I don't. And I especially dislike doing it in a change across all crates, without a reason to do it related to the dependency.

• I have made sure that the rust-version is only specified for public crates. The maintenance cost will be hopefully the exact same as it is now or even less after I have finished improving the CI. We can make it so that the developer doesn't have to edit the value themselves, even. The bot can do that.

I don't think having separate msrv for crates that are not standalone has enough value to bother, I don't think they should be added and I won't support adding those checks in CI. This can be revisited later for a 1.0 release, but for the moment the Bevy msrv policy is "latest stable", let's not go into details crate per crate.

[BenjaminBrienen]

Ok. I'd like to discuss the second point a bit more if you don't mind. I thought the design philosophy of bevy is to have each crate be usable on their own. A project could just use bevy_ecs, for example. Why wouldn't we want the usability there to be the same as the main bevy crate? This is assuming we set the msrv of bevy accurately for usability and to provide value to dependents. To me, it works the same way for each public crate. Can you please tell me your perspective on that aspect?

[alice-i-cecile]

Ok. I'd like to discuss the second point a bit more if you don't mind. I thought the design philosophy of bevy is to have each crate be usable on their own. A project could just use bevy_ecs, for example. Why wouldn't we want the usability there to be the same as the main bevy crate? This is assuming we set the msrv of bevy accurately for usability and to provide value to dependents. To me, it works the same way for each public crate. Can you please tell me your perspective on that aspect?

So, this ties into #16172. Only the standalone crates (bevy_ecs, bevy_math, bevy_color, bevy_ptr, bevy_reflect) should have their own MSRV. For any crate that relies on bevy_ecs, their MSRV should be fully tied to bevy_ecs, which for the foreseeable future is going to be on "latest stable".

[BenjaminBrienen]

I'll update this PR with the feedback when I have some free time. I'll fix some of the minor versions and remove more of the msrvs as requested. The main goal is consistency, correctness, and usability, so I'm glad to work with the feedback on that.

[BenjaminBrienen]

Marking as blessed because I reduced the scope to exactly the changes endorsed by @alice-i-cecile.

[alice-i-cecile]

I agree with this scope and these fixes :)