Skip to content
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.

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

Update release note process for current tooling #800

Merged
merged 1 commit into from
Jan 11, 2025

Conversation

Mark-Simulacrum
Copy link
Member

@Mark-Simulacrum Mark-Simulacrum commented Jan 11, 2025

r? rust-lang/release / cc @rust-lang/release
cc @RalfJung since you asked for it :)

Rendered

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 11, 2025
@BoxyUwU BoxyUwU merged commit 071f774 into rust-lang:master Jan 11, 2025
1 check passed
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).
Copy link
Member

Choose a reason for hiding this comment

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

FWIW I haven't seen this happen so far, is that new?

Copy link
Member Author

Choose a reason for hiding this comment

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

"new" maybe a strong descriptor -- it's not the typical process, for sure. Last I did relnotes (1.82?) I did do this for at least a few rounds of feedback.

Note that this step happens **on labeling**, not necessarily when the issue/PR
is merged/closed. (FIXME: Should we move this to close time, to make it more
likely that authors see the relnotes issue when it's warranted, particularly
for tracking issues?).
Copy link
Member

Choose a reason for hiding this comment

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

IIRC, when a PR gets merged the corresponding relnotes tracking issue gets put into the correct milestone associated with that release. Nothing like that happens for issues. Is that correct? Is there a step somewhere "find milestones for relnotes tracking issue without milestone"? I can't find such a step here.

Copy link
Member Author

Choose a reason for hiding this comment

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

I have a FIXME below for that:

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
milestones associated with them, which means their corresponding relnotes
tracking issue is probably never included (letting it get missed indefinitely).

And, yes, that's correct, under today's process those issues are very likely to be missed unless someone tags the stabilization PR with relnotes or milestones the issue itself accurately.

Copy link
Member

Choose a reason for hiding this comment

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

Yeah this happend in 1.84 where Pin::as_deref_mut was fcp'd on an issue not a PR so the associated relnotes issue was not in a milestone so it was not in the release notes

@Mark-Simulacrum Mark-Simulacrum deleted the relnotes-process branch January 11, 2025 21:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants