Release Gutenberg 15.2

[DaisyOlsen]

• Continuation of Release Gutenberg 15.1 #47411
  This issue is to provide visibility on the progress of the release process of Gutenberg 15.1 and to centralize any conversations about it.
  The ultimate goal of this issue is to keep the reference of the steps, resources, work, and conversations about this release so it can be helpful for the next contributors releasing a new Gutenberg version.

---

• Gutenberg version to release: 15.2 (milestone)
• Release Manager (a.k.a. Release Lead): @daisyo
• Release Date 15.2 RC: 15th Feb
• Release Date 15.2: 22nd Feb
• Release Weeks: Weeks 7-8 (from 23rd Jan to 12th Feb)
• Release Manager Buddy: @juanmaguitar
• Previous version changelog (as a reference): 15.1
• Previous version What's New In Gutenberg Post

Resources:

• Leading a Gutenberg Plugin Release
• Gutenberg Release Process | Block Editor Handbook | WordPress Developer Resources

Checklist

Note
A new major version of Gutenberg is released approximately every two weeks

Preparation (before Wednesday, Feb15th)

preparation usually happens before Wednesday of Week 1

• 📖 Read: Gutenberg Release Process
• 📽 Watch: Gutenberg Plugin: New Release Workflow
• 📽 Watch: Creating the Gutenberg plugin v12.0 Release Candidate
• 📽 Watch: Gutenberg plugin v12.0.0 Release Party!
• Organize and Label PRs on the relevant milestone

RC Day (Wednesday, Feb 15th)

RC Day usually is on Wednesday of Week 1

• Optional: Attend #core-editor meeting (Weekly meetings held Wednesdays at 14:00 UTC at the Slack channel)
• Post a message in #core-editor channel to let folks know you are leading the next GB release
• Post a message in #core-editor channel asking for a "Release Manager Buddy" to support you with the release (last person who did the release is a good candidate to help)
• Post a message in #core-editor channel to let folks know you are starting the RC release process
• Organize any last minute PRs for the changelog process
• Create Draft Release
• Changelog Created and Organized on Draft Release
• Publish (RC) Release
• Announce in #core-editor channel that RC1 has been released and is ready for testing
• Ping any other relevant channels announcing that the RC is available
• Create Draft Document of Release post to be published on Make Core blog (example)

Between RC and Release (from Wed Feb 15th to Wed Feb 22nd)

This period usually happens from Wednesday of Week 1 to Wednesday of Week 2

• Backport to RC see Release process docs for details
• Draft Release Post Highlights and changelog
• Get assets from Design team for the post
• Reach out to Highlight Authors to draft sections (if necessary)

Release Day (Wednesday 22nd February)

Release Day usually is on Wednesday of Week 2

• Ensure there are no pending Backport to RC
  • Is this done automatically when running the .zip workflow?
  • Is this operation only needed for minor releases?
• Check there are no open PRs in the proper milestone
• Check the release branch (release/15.2) build has no visible regressions
• Post a message in #core-editor channel to let folks know you are starting the release process
• Run Build Gutenberg Plugin Zip Action workflow for the stable version
• Organize and Label PRs on the relevant milestone
• Create Draft Release
• Changelog Created and Organized on Draft Release
• Publish Release
• Trigger the update to the plugin directory - SVN (get approval from member of Core team if necessary)
• Announce in #core-editor channel that the plugin has been released
• Reach out to other contributors to help get the post reviewed
• Publish Release post on Make Core blog

[juanmaguitar]

I think most of the PRs in this view have a proper label to be categorized based on the mapping you have here.
I have added a few labels missing on the PR's of this view:

• Added [Type] Code Quality to #47749
• Added [Type] Code Quality and [Type] Enhancement to #47844
• Added [Type] Code Quality to #47725
• Added [Type] Code Quality to #47875

I have checked that there are no PRs of the "Gutenberg 15.2" Milestone with no label.

I have also checked the PRs of the "Gutenberg 15.2" Milestone with no relevant Type ... labels, and from that list, I have added a few labels missing:

• Added [Type] Build Tooling to #45747

The rest of PR's from that filter (PRs in the milestone with no relevant [Type] ... labels) should be categorized appropriately:

Automated Testing → Tools
[Package] E2E Tests → Tools
[Package] Dependency Extraction Webpack Plugin → Tools

or should be ignored (not included in the Changelog) like the ones with Mobile App - i.e. Android or iOS label

[juanmaguitar]

I think some good next steps from here could be:

• Post a message (like this one) in #core-editor channel to let folks know you are starting the RC release process
• Create Draft Release
• Shape final Changelog from the draft Created
  • As the important [Type] ... labels are ensured you should have all PR's grouped in the most relevant sections (no "Various" section)
  • From that draft there's a work to assign PRs into subsections. For this I recommend you:
    • Use a Chrome add-on like Gitako so that every time you open a PR you have a quick view of the path of the files affected by the PR
    • Get inspiration from the subcategories used in previous releases (15.1 and 15.0)
• Once you have curated the changelog you can save the Draft and make the RC Release public

[DaisyOlsen]

Listing some other places where the process could be improved/streamlined as I go through this process. Some of these items are based on work I did in a previous release and the suggestions made during that process by those I worked with. This was before the release buddy concept was implemented.

The following are the items I've collected from just the pre-RC tasks. I'll continue to add more notes to this issue as I go along.

• The next release lead could be announced earlier or recruited if there is none. Release day during #core-editor seems like a great time. The current release lead could recruit the next lead as part of the announcement that the Release is being finalized.
• As soon as the milestone opens and PRs begin to be assigned to it PR labeling can (and should) begin. The PR labels are useful for the changelog organization, but they also create a historical and filterable record of PRs across the life of the project. My preference would be to do this work over the course of several days rather than all at once.
• The script that generates the categorized changelog might benefit from some refinements. There are newer labels not accounted for. The accessibility section could be handled in a more automated way.
• Titles for PRs should be concise, accurate, and informative. The changelog becomes much more easily understood if the general idea of each change can be gleaned without clicking through.
• Encourage PR contributors to write good titles and use labels. This makes the job of the release manager so much easier.
• I found it helpful to create a filtered list of PRs based on those that didn't have one of the labels used for the Types categorization of the changelog. I used a GitHub project board but the filter couldn't be saved because of the number of characters it took to exclude issues with all of the various labels. I'm going to give VSCode GitHub Issues Notebook extension a try to see if it could be a good tool for creating reusable filters. I am not sure if that extension would allow edits as easily as the GitHub Project Board.

[DaisyOlsen]

Message posted to Slack to announce that RC Process was starting.

🔈 FYI, I've started the RC release process for Gutenberg 15.2.
I'm nearly finished organizing and labeling PRs on the Gutenberg 15.2 milestone.
If you want to follow along, I'll record updates about the process on the Release Gutenberg 15.2 issue.

[DaisyOlsen]

The Release Post document has been created - let the Highlight selecting begin! cc: @priethor

[juanmaguitar]

The Release Post document has been created - let the Highlight selecting begin! cc: @priethor

@DaisyOlsen The Changelog needs to be curated more to improve its readability (especially for the stable release and the "What's New...." blog post)
Ideally, we shape it, so there are no subsections with less than three items (exceptionally two items).

I have opened the following working doc with a few suggestions (as a reference) for reorganizing the Changelog to improve its readability:
https://docs.google.com/document/d/13jRMEkvO1P5d6KWNnqovz3XVBL7d2HQr8Q95V52lobM/edit#

PS: I don't think this is well explained anywhere in Gutenberg Release Process, so explaining this is another improvement that could be made on these docs.

[DaisyOlsen]

Thanks for this @juanmaguitar I'm aware that the changelog requires more refinement. I appreciate the help. Is there a reason for separating the work out into a new document rather than making suggestions right in the draft?

[DaisyOlsen]

I've mentioned that an RC2 will be coming in #core-editor

[juanmaguitar]

Is there a reason for separating the work out into a new document rather than making suggestions right in the draft?

Not really. It was just to remove some noise from the original comment, as I wanted to add a comment per every change of position.

Feel free to copy and paste my suggestions over the Changelog from this additional doc into the Release Post document if you agree with them, and continue the work from there.

[DaisyOlsen]

No need to worry about the Performance Test results until the final release.

I was able to resolve a problem with creating the RC2 release draft before changing the milestone on the relevant PR. The PR had been included in the release, but the changelog wasn't generated correctly. @jorgecontreras was able to confirm that this was the case, and the RC has now been published.

The instructions here could be updated to be made more clear.

[DaisyOlsen]

I've worked through the changes suggested by @juanmaguitar in a separate document mentioned above. Will continue with changelog refinements and hopefully get started on highlights early next week.

[DaisyOlsen]

Noting for later so I can batch things for improvement after the release.

Accessibility issues should be grouped together into one top-level category rather than being mixed in with other PRs. The Release process docs should be expanded to include this and other information about exactly how we should be shaping the changelog.

[juanmaguitar]

The Release process docs should be expanded to include this and other information about exactly how we should be shaping the changelog.

I agree. Some notes about this that could be useful (based on @priethor's)

The responsibilities of the Gutenberg Release Lead/Manager usually include:

• Group the changelog entries in a way that makes it readable.
• Be proactive in communication to pick impactful highlights.
• Write a "quality" post.

We could translate those into:

• Polish the changelog so that:
  • There are no uncategorized items.
  • Items are not in the wrong category (e.g., an enhancement marked as a bug).
  • There are no subsections with just one or two items (whenever possible)
• Be proactive in communicating the release status so that design and product can review/propose highlights early enough.
• Draft a release post that explains why the highlights are impactful in.
  • Sharing this draft with the community as soon as possible to gather feedback
• Ship it on the same day as the release (or as soon as possible after the release time).

[DaisyOlsen]

The release process is complete from a GitHub perspective. A first request to push the updated plugin to the plugin directory has been made in #core-editor

Performance tests have failed - an issue about this has been created and shared in #core-editor in Slack for visibility.

[DaisyOlsen]

For the list of things to consider for future releases - I wonder if it might be beneficial to have a "Merged PR" triage process that isn't necessarily only the responsibility of the Release Lead.

I've begun watching and labeling PRs as they are merged and I'm finding it to be a good way to keep tabs on the project as well as prepare things proactively for the next release.

[DaisyOlsen]

Watching a conversation regarding the need for a Core committer or Core Editor team member to publish the plugin here: https://wordpress.slack.com/archives/C02RQBWTW/p1677092911714069?thread_ts=1677084987.110319&cid=C02RQBWTW

Nothing to report from there at this point, but will see if it progresses.

[DaisyOlsen]

For both the 15.2 and 15.2.1 releases getting the update pushed out to the plugin directory has required quite a bit of wrangling. The best way to get the attention of someone that has both the right credentials and availability at the time the task is ready for action is unclear. General requests in #core-editor and #core are ok but are not a guarantee of being acted upon.

[DaisyOlsen]

The release post has been published https://make.wordpress.org/core/2023/02/24/whats-new-in-gutenberg-15-2-22-february/