-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Post 2.50.0 Streamline release guide improvements #28287
Conversation
Stopping reviewer notifications for this pull request: review requested by someone other than the bot, ceding control |
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.
Thanks for doing this!
PTAL |
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.
LGTM
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 hate hate HATE markdown that is only readable when rendered (aka using a sequence of 1. 1. 1. 1.). But you didn't start the fire, for the most part...
I'm right there with you, but I'd make that a separate change across the whole file rather than adjust the untouched lists here, or only partially convert it. |
This is a larger cleanup of the release guide to clarify timings and positioning of the broader steps.
Larger emphasis has been put on the Release Manager's role prior to the release cut. If issues are addressed in the main branch before the cut, they do not need to be addressed afterwards. The release manager is empowered to do so.
Clarify some timing around the begining and end of the release by calling out the preparation steps should be performed within the week prior to the release cut. Also call out that release finalization tasks can be done within a few hours of the release being completed.
While the guide isn't materially shorter, maintaining the simpler structure as in the overview will make it less overwheling to release managers, since it's clearer when the various subtasks apply, vs the previous "13" steps. This should clarify the "build release candidate + vote + fix" loop that is the bulk of a release manager's tasks. I believe this will help get to release candidates sooner.
Add a new section "Post Release Tasks" which is where the Playground update task lives. While it's part of the release tasks, it doesn't block the release overall, so it felt weird structurally to have it as important as "Build a Release Candidate".
Various minor typos and fixes.
Rendered version should become available here:
http://apache-beam-website-pull-requests.storage.googleapis.com/28287/contribute/release-guide/index.html
Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:
addresses #123
), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, commentfixes #<ISSUE NUMBER>
instead.CHANGES.md
with noteworthy changes.See the Contributor Guide for more tips on how to make review process smoother.
To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md
GitHub Actions Tests Status (on master branch)
See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.