-
Notifications
You must be signed in to change notification settings - Fork 180
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
Conversation
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). |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?). |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
r? rust-lang/release / cc @rust-lang/release
cc @RalfJung since you asked for it :)
Rendered