-
-
Notifications
You must be signed in to change notification settings - Fork 3.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix reflected serialization/deserialization on Name
component
#11447
Conversation
Since this is technically a breaking change (i.e. existing scenes could now be invalid and/or expectations of what's included in the serialized output), could you add a migration guide? |
It looks like your PR is a breaking change, but you didn't provide a migration guide. Could you add some context on what users should update when this change get released in a new version of Bevy? |
Just saw this now, but the PR is already merged. 😕 Are we using the reflection (de)serialization for scenes? In this case I can add an entry to the migration guide, will the release script still pick it up even after the PR is merged? Will we need to include it manually later when writing the notes? |
Yep! It's what powers the scene system essentially.
I believe the script is only run towards the end of the cycle. So it should pick it up if you add it now. |
This doesn't seem to be working in 0.13? https://discord.com/channels/691052431525675048/1019697973933899910/threads/1209244908372627507 |
Objective
ReflectSerialize
andReflectDeserialize
traits are properly derived onName
. This avoids having the internal hash “leak” into the serialization when using reflection.Solution
ReflectDeserialize
andReflectSerialize
via#[cfg_attr()]
Changelog
Name
now correctly implementsReflectDeserialize
andReflectSerialize
whenever theserialize
feature is enabled.Migration Guide
Name
component will require patching. Search forbevy_core::name::Name
, and replace the following structure( "name": "My Entity Name", "hash": ... )
with just a string:"My Entity Name"
.