Block Editor Release Process for Major Releases

This guide will clarify how to handle the Editor (GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/) portion of a major WordPress release. This is a living document. You are encouraged to leave feedback and provide updates.

Release team roles

It takes a team to manage the Editor release process for each major version of WordPress. You can learn more about the roles and responsibilities of each key role below. 

• Editor Tech Leads
• Editor Triage Leads
• Documentation Leads

Quick reference timeline

Here’s a list of the significant time-critical tasks, sorted by when they should be completed. More details about each task are available later in this document.

Two months before BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1

• Set up the release project board on GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/
• Audit experimental APIs in Gutenberg
• Create an overview issue for PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 7.4 or higher changes that need to be manually added in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. The issue should have the label “🤖 Sync Backportbackport A port is when code from one branch (or trunk) is merged into another branch or trunk. Some changes in WordPress point releases are the result of backporting code from trunk to the release branch. Changelog” and the WP version x.x in the title, so that the PR list is auto-generated.

One month before Beta 1

• Update trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running “trunk”, then you are on the latest revision. with the latest Gutenberg packages and PHP changes
• Create a tracking issue for dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase., which should be published by RC1 and require plenty of time to wrangle

Between Beta 1 and the last RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta).

• Create a label “Backport to WP x.x Beta/RC”.
• Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. recent bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. reports and unlabelled issues for critical regressions
• Fix all critical regressions and as many bug fixes related to the release as possible

The week before each Beta/RC release

• Go through all PRs labeled “Backport to WP x.x Beta/RC” and check that they are ok to include in the release. Check the merged PRs with this label for any auto-cherry-pick failures.
• Review any open PRs with the same label
• Go through the commits on the wp/x.x branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a “branch”, such as “the 4.0 branch”. to ensure the PR should be included in the release.
• Start package update/core patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. process

Planning before the first Major Release Beta

At the start of each release cycle, a planning roundup post should be published (example from 6.3) that details key milestones leading up to the major WordPress release. This post includes deadlines for all Beta and RC releases and the names of all release team members. 

Scheduling the last editor release and communicating deadlines

Gutenberg releases happen biweekly, so you can determine which Gutenberg release is scheduled closest to Beta 1 and, if necessary, rearrange the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party release date to align better with Beta 1. 

Ideally, this last Gutenberg RC should be released 4-5 days before Beta 1. This schedule will give plenty of time for any bugs to be identified and fixed while allowing the team to publish npm packages and update their versions in Core. 

If a contributor wants to include a new Editor feature in the major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope., it must be included in this last Gutenberg RC. Therefore, once you have identified the final Gutenberg release, share it in the #core-editor SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel and during the weekly Editor Weekly Chat meeting to allow contributors to prepare appropriately.

The Roadmap post

A Roadmap post identifies the features, enhancements, and bug fixes slated for the current major release (example from 6.3). The creation of this resource is a collaborative effort between release leads and contributors.

You should become familiar with this post if you are an Editor Tech or Triage lead. It’s an excellent resource for knowing what should be included in the release. It’s also invaluable for determining which reported issues are related to the release and which need to be added to the project board. More on that below. 

Managing the project board

Creating a “project board” for the major release in Gutenberg’s GitHub repository has become a best practice. This board helps coordinate tasks and should contain all issues and PRs related to the release.

Setting up the project board

Beginning with WordPress 6.3, a template has been created to help you set up the project board. 

• Navigate to the template: WordPress (X.X) Editor Tasks
• Click on the “Use this template” button to create a new board
• Update the title of the board using the format “WordPress X.X Editor Tasks”
• Update the “Punted to 6.X.1” and “Punted to 6.Y” column titles
• Navigate to the Gutenberg Projects page and click the “Link Project” to link the newly created project to the Gutenberg repository. 

The template will contain the following columns:

• Triage – All new issues enter the board in this column. Release leads then decide if the issues belong in the “Todo”, “In discussion / Needs decision” or other columns as needed. Issues can also be removed from the board completely if there is a general consensus among leads.
• In Discussion / Needs Decision –  Contains issues or PRs that the team needs more time to consider for the release. Some possible reasons for not having a conclusion are:
  • The problem was critical but was impossible to replicate, so it’s a matter of waiting for more information to understand the specific conditions where the problem happens.
  • It still needs to be clarified if the issue is a regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A “3.6 regression” would be a bug in 3.6 that worked as intended in 3.5. or not, or it is not clear if the issue is a bug or desired behavior.
  • The issue requires a complex testing setup, and replicating it takes time. In this case, you should write a comment upon finding the issue, saying what must be done to test it. This helps make it easier for others to help with testing. If needed, you may need to add the “needs-testing” label as well. Once the issue is tested and confirmed, move it to the “Todo” column. 
• Todo – Contains issues that the team has determined should be fixed by the release but do not have a PR associated with them.
• In Progress – Contains issues that the team has determined should be fixed by the release and have a PR associated with them.
• Needs Review – Contains PRs associated with issues in the “In Progress” columns that are not yet merged and need review.
• Needs Core Commit – Contains PRs that need an additional Core commit, which the Editor Tech Leads determine. 
• Done – Contains issues and PRs that are complete.
• Punted to 6.X.1 – Contains issues and PRs that the team has determined should be punted to the next minor releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality..
• Punted to 6.Y – Contains issues and PRs that the team has determined should be punted to the next major release.

After you have created the project board, make sure to review the project board from the prior release and migrate over all punted issues and PRs. Remove each from the old project board once you have moved everything over.