bevy/release-content/migration_guides_template.md
Miles Silberling-Cook 0a2e183476
Add basic release content tagging workflow (#18568)
# Objective

This PR begins integrating the new releate-content drafting process
(https://github.com/bevyengine/bevy/pull/18427) into our GitHub
workflows. It's similar to what we had before: Messages are posted to
PRs tagged with `M-Needs-Release-Note` or `M-Needs-Migration-Guide`
asking them to add the required material and linking to the
instructions. These messages do not trigger if the PR already has
modified files in the `release-notes` or `migration-guides` directories
(respectively).

I have also re-arranged and content slightly (to remove the need for a
directory with the current version number), tweaked the language, and
switched the templates to use the [standard markdown frontmatter
format](https://jekyllrb.com/docs/front-matter/).

## Reviewer Questions

+ Do we want to add a CI rule actually requiring tagged PRs to
create/modify files in the correct directories, or is the message prompt
enough?
+ Do we want to add a CI rule to lint the metadata, for example to
enforce that the PR number is included in the files it modifies?
2025-03-27 17:46:39 +00:00

31 lines
760 B
Markdown

---
title: Feature that broke
pull_requests: [14791, 15458, 15269]
---
Copy the contents of this file into a new file in `./migration-guides`, update the metadata, and add migration guide content here.
## Goals
Aim to communicate:
- What has changed since the last release?
- Why did we make this breaking change?
- How can users migrate their existing code?
## Style Guide
Keep it short and sweet:
- Use bullet points and make sure it's searchable.
- Avoid headings. If you must, use only level-two headings.
- Use backticks for types (e.g. `Vec<T>`) in either the title or the body.
- Diff codeblocks can also be useful for succinctly communicating changes.
```diff
fn my_system(world: &mut World) {
+ world.new_method();
- world.old_method();
}
```