# 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?
# Objective
As discussed in #https://github.com/bevyengine/bevy/discussions/16431,
our release process is a major bottleneck, difficult to collaborate on
and a serious source of burnout (hi!). Writing all of the release notes
and migration guides at the end of the cycle is miserable, and makes it
harder to coalesce them across multiple PRs doing related work.
## Solution
This PR largely implements the solution designed and discussed in the
[Better release
notes](https://discord.com/channels/691052431525675048/1331412459432710247)
working group, unofficially led by @NthTensor. The
[plan](https://hackmd.io/NBKkrGbbS5CaU7PsQUFGJQ) laid out in the linked
HackMD has largely been folllowed, although I've also added Migration
Guides too: they suffer much the same problem.
I've also moved away from using the PR number as the title for the file:
if we're hand-authoring the files we can do much better than that!
The READMEs for each folder describe the process in more detail: please
read (and comment on them!).
## Questions for reviewers / fellow implementers
- I've moved away from the current "store metadata in a mega-file"
approach, and moved it towards a "put the metadata in the file you're
editing" design. I much prefer the locality, but it may be harder to get
to play nice with our website generation. Do you want me to revert that?
See [this
folder](https://github.com/bevyengine/bevy-website/tree/main/release-content/0.15)
for the current format.
- does the "how to write release notes / migration guides" sections make
sense to you here? Normally I would toss this in the Contributor's
Guide, but I do like it being right beside the spot you're making
changes
## Follow-up work
- [ ] add a job which checks for the labels and blocks the PR if no file
in the correct folder is merged
- [ ] add a CI job to do basic format validation on the files inside of
these folders
- [ ] generate the release notes and migration guides using a modified
version of [the
tooling](https://github.com/bevyengine/bevy-website/tree/main/generate-release)
one last time for 0.16
- [ ] remove the release notes and migration guide generating tools
- [ ] build a new pipeline to turn the copy-pasted release notes here
into actual website content
- [ ] rethink how we're doing release notes to provide better punchy
summaries for casual readers
- [ ] create a CI job that checks for new or edited migration guides and
automatically labels the PR
---------
Co-authored-by: Joona Aalto <jondolf.dev@gmail.com>
Co-authored-by: Zachary Harrold <zac@harrold.com.au>
