From f72738b7d7be518cc1e92496fef99b3e74296532 Mon Sep 17 00:00:00 2001 From: Boxy Uwu Date: Wed, 24 Jun 2026 13:26:36 +0100 Subject: [PATCH] update relnotes process --- src/release/release-notes.md | 78 ++++++++++++++++++++++++------------ 1 file changed, 52 insertions(+), 26 deletions(-) diff --git a/src/release/release-notes.md b/src/release/release-notes.md index db6bd9576..187420a6c 100644 --- a/src/release/release-notes.md +++ b/src/release/release-notes.md @@ -75,11 +75,16 @@ jumps out as *should have been nominated* and nominate it by tagging with relnotes. Scrolling through the list without clicking through and using the GitHub checkbox UI to mass-label issues is a good strategy. +Standard library stabilizations are often missed as FCPs happen on unmilestoned +issues rather than stabilization PRs. It can be useful to search the standard +library for any APIs with stability attributes with `since = "1.xx.0"` and then +find the corresponding stabilization PR to tag with `relnotes`. + The goal here is mostly **catching obvious things**, not 100% exhaustiveness. It's generally OK if we miss something. If there's a consistent pattern, note it down for inclusion in triagebot's automatic issue filing. -[Search]: https://github.com/rust-lang/rust/pulls?q=is%3Apr+milestone%3A1.85.0+is%3Amerged+-label%3Arelnotes+-label%3Arelnotes-perf+-label%3Afinished-final-comment-period +[Search]: https://github.com/rust-lang/rust/pulls?q=is%3Apr+milestone%3A1.97.0+is%3Amerged+-label%3Arelnotes+-label%3Arollup+-label%3Arelnotes-perf+-label%3Afinished-final-comment-period+ FIXME: This step may also need to include an attempt to milestone any **issues** that got tagged relnotes and closed -- those currently don't get @@ -96,9 +101,11 @@ tool. ```shell cargo build -GITHUB_TOKEN=$(gh auth token) cargo run --bin relnotes -- 1.85.0 > relnotes.md +GITHUB_TOKEN=$(gh auth token) cargo run --release 1.85.0 --draft > relnotes.md ``` +Note that the release number should include the patch version (`.0`). + This produces console output (stderr) like this: ```text @@ -127,31 +134,32 @@ present *but shouldn't be*, the best thing is to tag it with relnotes (or find the pre-existing relnotes tracking issue) and *close that tracking issue*. This will also drop the item from the tool's output. -## Release team: Step 5: Publish relnotes PR +## Release team: Step 5: Open draft relnotes issue -See example from 1.84: +An issue titled "Draft release notes for 1.xx.0" should be opened with the output +of the relnotes tool pasted into the description. Then, as a comment the release team +and relnotes-interest-group should be pinged: +```console +@rustbot ping relnotes-interest-group -Take the `relnotes.md` you have locally (typically without library -stabilizations in today's world, you'll add them at a later point -- we want -the copy without them as early as possible), and insert it at the top of -RELEASES.md in rust-lang/rust, and open a new PR with those contents. You can -`r?` the owner for actually publishing the release for this cycle and cc the -release team. +cc @rust-lang/release +``` -Include a link to this document (https://forge.rust-lang.org/release/release-notes.html) -in the PR description, pointing at step 6 (i.e., prefer suggesting updates not on the PR). +This issue should be labelled as `T-release` and `relnotes-tracking-issue` then +pinned so that it appears at the top of the issue tracker. -The next release team meeting should also discuss this PR for selecting blog -post topics (see below for blog post process). +The draft of the release notes should be periodicially regenerated until it is +time to finalize the release notes with a PR. -### Pinging `relnotes-interest-group` for relnotes PR and release blog post -Contributors may be interested to help review the relnotes PRs and release +### Pinging `relnotes-interest-group` for relnotes and release blog posts + +Contributors may be interested to help review the relnotes and release blog posts (e.g. on behalf of their team). They can opt-in to being pinged by adding themselves to the [`relnotes-interest-group` marker team][relnotes-interest-group]. -When creating a relnotes PR and release blog post, please ping this +When creating a relnotes draft, relnotes PR or the release blog post, please ping this notification group via ```console @@ -160,21 +168,39 @@ notification group via [relnotes-interest-group]: https://github.com/rust-lang/team/blob/main/teams/relnotes-interest-group.toml -## All: Step 6: Incorporate edits from relnotes PR +## All: Step 6: Incorporate reviews on the draft -You'll typically get a lot (several dozen) of comments on the PR with typo -fixes, suggestions for alternative text, etc. A good strategy is to try to -update the originating issues for issues/PRs (or file them and update them), -essentially matching the iteration already done locally in step 4. The longer -state stays in issues the easier it is to notice and incorporate updates from -those into the PR (just rerun the tool). +You'll typically get a lot (several dozen) of comments on the issue with typo +fixes, suggestions for alternative text, etc. The originating issues tracking +the release notes should be updated in response, essentially matching the iteration +already done locally in step 4. Pushing edits into the issues helps bring the right people (e.g., PR author/reviewer) into the loop on what is getting discussed. -## Release team: Step 7: Close tracking issues +## Release team: Step 7: Publish relnotes PR + +See example from 1.84: + +The relnotes tool should be re-invoked this time without `--draft` and +insert the output at the top of RELEASES.md in rust-lang/rust, and open +a new PR with those contents. You can `r?` the owner for actually publishing +the release for this cycle and cc the release team. + +Include a link to this document (https://forge.rust-lang.org/release/release-notes.html) +in the PR description, pointing at step 6 (i.e., prefer suggesting updates not on the PR). + +The relnotes-interest-group should once again by pinged: +```console +@rustbot ping relnotes-interest-group +``` + +The next release team meeting should also discuss this PR for selecting blog +post topics (see below for blog post process). + +## Release team: Step 8: Close tracking issues -At some point, the release team owner should declare the PR authoritative and +At some point, the release cycle owner should declare the PR authoritative and close all relnotes tracking issues associated with the current milestone ([sample search](https://github.com/rust-lang/rust/issues?q=is%3Aissue%20state%3Aopen%20milestone%3A1.85.0%20label%3Arelnotes-tracking-issue)). Doing this in the GitHub UI is easiest. FIXME: Ideally those would all get linked from the relnotes PR, so it's easier