Consider renaming or rearchitecting `AssetEvent`

[janhohenheim]

What problem does this solve or what need does it fill?

After the event rearchitecture, we have two distinct names for two distinct but related concepts:

• Messages are buffered
• Events are immediately handled

As mentioned in that PR, we should not use a suffix to indicate whether something is an event or a message. Rather, the types should reflect what information is being transmitted (Collision is better than CollisionMessage).

But there's a bit of a conflict here for some types that happen to have Event in its name, as it is notifying the API caller about some kind of "event", where "event" does not mean Bevy's notion of event, but "something changed or happened"

In my personal migrations, I have a ton of code now that reads MessageReader<AssetEvent>. This is confusing. And if I'm confused by this, I think a newcomer will be even more confused.

What solution would you like?

Rename at least AssetEvent as it's somewhat common. Maybe also others like RawWinitEvent if we have a nice solution, but that's secondary. @viridia suggested Status as a suffix, which I think conveys the meaning well when read in MessageReader<AssetStatus>: here's a Message about the new status of the asset.

What alternative(s) have you considered?

• Leave it
• Document extremely clearly how our naming works everywhere a beginner might read it
• Use a different suffix
  • Per discussion below: AssetChange, AssetLifecycle

Additional Information

Relevant PR: #20953
See @janis-bhm's comments there

[alice-i-cecile]

AssetStatus gets my vote for new name: much clearer and better scoped.

I'm a little leery about putting breaking changes into 0.17 at this point (since it will force a republish by any crates who have already migrated), but I think it's worth it here. @cart @mockersf, do you have opinions here?

P.S. Long-term I would probably like to make this a true Event, following #11266, but AssetEvent is a mediocre name even after we do that.

[andriyDev]

Hmmm I'm not a fan of AssetStatus because an asset's status can differ from what is reported: you can get AssetStatus::Added, AssetStatus::Modified, AssetStatus::Removed all in a single system for a single asset.

Thoughts on just calling it AssetChange? It kinda overlaps with AssetChanged, but I think it more clearly indicates that you could have multiple changes in a frame?

[alice-i-cecile]

Maybe AssetLifecycle? I agree that it's important to communicate that this is event-like, not status-like, in some way.

[janhohenheim]

I also like those suggestions :)

[mockersf]

I'm a little leery about putting breaking changes into 0.17 at this point (since it will force a republish by any crates who have already migrated), but I think it's worth it here. @cart @mockersf, do you have opinions here?

We can duplicate the event with a new name and deprecate the old one.

We will send twice the events for the period, but I think it's ok as assets shouldn't be high frequency changes

[alice-i-cecile]

I think a type alias should do the trick just fine without having to duplicate events :)

[andriyDev]

Do we need a depreciation here? The RC period still seems like a reasonable time to ship breaking changes (when necessary), and it seems weird for asset events to have a "softer" migration than the much more disruptive event/message stuff.

I don't think authors who have published an RC.1 version of their crate are expecting to not have to do more migrations, and I'm not sure if we should be cultivating that mindset.