mirror of
https://github.com/bevyengine/bevy
synced 2024-11-10 07:04:33 +00:00
c1a2378790
# Objective Context: [Discord Discussion](https://discord.com/channels/691052431525675048/745355529777315850/950532143325519902) Improve the PR template by adding "Changelog" and "Migration Guide" sections. These sections should hopefully help speed up the review/merge process, as well as help make release notes and migration guides. ## Solution Added the "Changelog" section template which suggests listing out the changes of the PR. This also acts as a sort of tl;dr for reviewers (especially for larger PRs). Added the "Migration Guide" section template which suggests describing how a user might need to migrate their codebase to account for the changes by the PR. This also helps authors/contributors keep the end-user in mind when adding or changing the API. Both sections are optional— an author does not _need_ to fill these out. Hopefully they will, though, as it provides a handful of really great benefits. Co-authored-by: MrGVSV <49806985+MrGVSV@users.noreply.github.com>
1.1 KiB
1.1 KiB
Objective
- Describe the objective or issue this PR addresses.
- If you're fixing a specific issue, say "Fixes #X".
Solution
- Describe the solution used to achieve the objective above.
Changelog
This section is optional. If this was a trivial fix, or has no externally-visible impact, feel free to skip this section.
- What changed as a result of this PR?
- If applicable, organize changes under "Added", "Changed", or "Fixed" sub-headings
- Stick to one or two sentences. If more detail is needed for a particular change, consider adding it to the "Solution" section
- If you can't summarize the work, your change may be unreasonably large / unrelated. Consider splitting your PR to make it easier to review and merge!
Migration Guide
This section is optional
- If this PR is a breaking change (relative to the last release of Bevy), describe how a user might need to migrate their code to support these changes
- Simply adding new functionality is not a breaking change.
- Fixing behavior that was definitely a bug, rather than a questionable design choice is not a breaking change.