Skip to content

update relnotes process #1076

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.

Sign up for GitHub

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

Open
BoxyUwU wants to merge 1 commit into
base: master
Choose a base branch
from
Open

update relnotes process #1076

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
78 changes: 52 additions & 26 deletions src/release/release-notes.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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`).

@Mark-Simulacrum Mark-Simulacrum Jun 24, 2026 •
edited by rustbot
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we enforce this in the tool?

View changes since the review

@BoxyUwU BoxyUwU Jun 24, 2026 •
edited
Loading

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I intend to do so yeah, havent gotten around to doing impl changes to the tool so just wanted to write it down somewhere first so I don't forget the footgun :3


This produces console output (stderr) like this:

```text
Expand Down Expand Up @@ -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: <https://github.com/rust-lang/rust/pull/134568>
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
Expand All @@ -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: <https://github.com/rust-lang/rust/pull/134568>

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
Expand Down