Document Bevy crate tiers and expectations

[mockersf]

Bevy has many crates, with various level of expectations. I would like those levels to be documented, with their expectations and where they currently stand.

I think the current status is:

• Tier 1: bevy!
  • Code must compile on all platforms (macos, windows, linux, android, ios, wasm)
  • Features must be documented
  • Examples must be documented
  • Selected examples must run on all platforms
• Tier 2: standalone crates: bevy_ecs, bevy_reflect, bevy_color, ...
  • If the crate has unsafe code, run through miri
  • If the crate can build in no std, check it
  • Build without default features
• Tier 3: all the others
  • Not much

Tier 3 is mostly useful to plugin authors and power users, and is lacking in documentation. For example, documenting features of all crates would have a lot of value.

Things to do:

• [ ] document current state
• [ ] agree on expectations

[alice-i-cecile]

I don't like the numbered tiers, but I agree that a categorization system would be useful!

Proposal:

• core: part of Bevy's default feature set, used to create a cohesive game engine. These must work on all platforms, be fully documented and so on.
• standalone: crates that can be used on their own but are designed specifically for Bevy. Cannot pull in bevy_ecs.
• utility: small, stable crates that Bevy happens to maintain, but are not actually tied to Bevy. These belong in the Bevy org but not the Bevy repo.
• optional: game engine functionality that isn't used by many games. Meshlets for example belong here, as would something like tilemap support. Most of the editor-supporting crates and dev tools seem like they belong here too.