-
Notifications
You must be signed in to change notification settings - Fork 353
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
[Merged by Bors] - Migration guide 0.9-0.10 #530
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we consider a scheme for grouping/prioritizing certain changes? The ones that break builds are immediately obvious, but the behavioral/default changes, especially the ones that affect safety, seem like they deserve to be highlighted separately.
<div class="migration-guide-area-tag">ECS</div> | ||
</div> | ||
|
||
- Safety invariants on `bevy_ptr` types’ `new` `byte_add` and `byte_offset` methods have been changed. All callers should re-audit for soundness. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Breaking changes to safety invariants seem like they could insidiously hard to find, and the consequences result in UB. Should we show some higher priority to these?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right now, the only sort is by area and then by close date. I have no issue with changing ordering, although, I think this should keep the area ordering. So in this case, keep it close to other ECS related guides. As mentioned in another comment, I'd prefer waiting until closer to release before actually moving it so I'll leave the conversation opened.
cf5b834
to
7d5bb38
Compare
|
Co-authored-by: James Liu <[email protected]>
5705568
to
21f380a
Compare
bors try |
tryBuild failed: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Made a full pass on all changes. I wasn't able to check if all migration guides are correct, but I did what I could.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When migrating to 0.10.0, I had to replace usage of
Before:
// cam: Camera
cam.target
.get_render_target_info(&windows, &images)?
.physical_size
.as_vec2()
After:
// cam: Camera
cam.physical_viewport_size()?.as_vec2()
Not sure where this goes, but it's a change I had to do when migrating
Just leaving a note here not to forget to add bevyengine/bevy#7778 if it gets merged before 0.10 is ready. It's not necessarily a breaking change, but it does document a new safety invariant that should be publicly documented in some way. |
Co-authored-by: Edgar Geier <[email protected]> Co-authored-by: Afonso Lage <[email protected]> Co-authored-by: TimJentzsch <[email protected]> Co-authored-by: Rob Parrett <[email protected]>
Co-authored-by: ickshonpe <[email protected]> Co-authored-by: Rob Parrett <[email protected]>
@nicopap it looks like all those functions still exists, so I'm not sure anything needs to be migrated. |
Co-authored-by: Liam Gallagher <[email protected]>
|
||
### [Remove `TextError::ExceedMaxTextAtlases(usize)` variant](https://github.com/bevyengine/bevy/pull/6796) | ||
|
||
<div class="migration-guide-area-tags"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Formatting is broken in the preview starting here. Is there an unclosed tag or something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems to work correctly for me when running it with zola locally, do you have a screenshot?
A lot of users have been asking about multiple fixed timesteps, so here's a suggestion to add a section. Multiple fixed timestepsOnly one fixed timestep is supported. If you were relying on this functionality, you should swap to using timers, via the |
Co-authored-by: JoJoJet <[email protected]>
@alice-i-cecile do you know what PR is related to this change? Should I just add it to the schedule_v3 section? |
It was part of the ScheduleV3 rewrite. Just stick it in that section. |
Co-authored-by: Alice Cecile <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great work yall! Another fantastic release :)
bors r+ |
First draft of the 0.10 migration guide. This is generated by #469 and then modified manually Since this is easy to generate, I will re-generate it multiple time before release so changing the contents of guides is encouraged, but changing ordering should be done closer to release to avoid dealing with multiple conflicts. For this migration guide, I added tags for areas of each PR, added a bit of spacing and a line for each heading ![image](https://user-images.githubusercontent.com/8348954/216899165-6f99a25f-e32d-42a4-bad4-8e23c7aac366.png) This is why there are some css files in this pr. Co-authored-by: IceSentry <[email protected]> Co-authored-by: Carter Anderson <[email protected]>
Pull request successfully merged into master. Build succeeded: |
First draft of the 0.10 migration guide.
This is generated by #469 and then modified manually
Since this is easy to generate, I will re-generate it multiple time before release so changing the contents of guides is encouraged, but changing ordering should be done closer to release to avoid dealing with multiple conflicts.
For this migration guide, I added tags for areas of each PR, added a bit of spacing and a line for each heading
This is why there are some css files in this pr.