Merging Gutenberg 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/ to WordPress on major releases is now more automated than ever.
@zieladam (me) and @gziolo were the tech editor release leads for WordPress 6.0. We’ve quickly noticed that ~30% of the role is about communication and decision making, while ~70% consists of repetitive weekly chores. We want to reverse these proportions.
Most repetitive work falls into one of the two categories:
- Backporting PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher changes made in the Gutenberg plugin 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 since the previous major WordPress release
- Releasing weekly Beta 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./RC 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). versions
Backporting PHP changes made in the Gutenberg plugin since the previous major WordPress release
Finding and backporting all the PHP Pull Requests merged to Gutenberg but not to WordPress core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. is a huge task.
For WordPress 6.0, it took us two days just to prepare the list. From there, it was two weeks of pinging, coordinating, reviewing, and merging code before we were done. Furthermore, not all the authors had the availability to help at that point in time.
This cannot be easily automated, but imagine the alternative: Gutenberg developers prepare PRs against WordPress core in parallel with merging their Gutenberg PRs. Any integration issues get surfaced right away, there are fewer merge conflicts, and the release leads don’t have to spend two weeks investigating the commit history and pinging code authors. The future availability of the developers isn’t a problem anymore either.
If that sounds appealing, come and speak up in the ongoing GitHub discussion!
Releasing weekly Beta/RC versions
The weekly release consists of four repetitive tasks:
- Cherry-pick triaged code to a Gutenberg release branch 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".
- Release Gutenberg
@wordpress packages from that branch - Update the version of packages used in
wordpress-develop - Manually stabilize any blocks to be included in the new release
@zieladam (me) and @gziolo added a degree of automation to all of the above.
Cherry-pick triaged code to a Gutenberg release branch
Bringing Gutenberg Pull Requests over to WordPress after Beta 1 requires cherry-picking the relevant commits.
Before, this involved manually resolving conflicts and letting the author know. A few times I got confused and spent more time on it than I hoped to.
Today, the new npm run cherry-pick script automates all of that (except resolving conflicts). Furthermore, it can be repurposed for the Gutenberg plugin releases.
Publish the updated @wordpress packages from the release branch
After cherry-picking the relevant changes to the release branch, the way to bring these changes to WordPress core is through npm packages.
Before, it took publishing permissions, a specific local setup, and remembering the correct command with the proper CLI Command Line Interface. Terminal (Bash) in Mac, Command Prompt in Windows, or WP-CLI for WordPress. parameters. With all that in place, you ran the built process, waited a longer while, and then published the packages.
Today, this entire process can now be triggered directly from GitHub UI after approval from any Gutenberg core team member.
Update the version of packages used in wordpress-develop
With fresh @wordpress packages published to the NPM registry, the next step is to update the dependencies in wordpress-develop.
Before, it involved a manual synchronization of the new Gutenberg dependencies with the package.json JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. file shipped in wordpress-develop. You had to add any new dependencies, update the versions of the existing ones, and delete ones that were no longer used.
Today, the new sync-gutenberg-packages console task automates this effort.
Manually stabilize any blocks to be included in the new release
Finally, a number of steps are required to enable the new stable blocks in WordPress core.
Before, you had to manually list the new blocks in a few .php and .js files and double- or triple-check whether all these lists are in sync. As there are other build steps at play, the resulting Pull Request is quite large. Even though @zieladam and @gziolo were careful, we still ended up making mistakes.
Today, the new sync-stable-blocks console task reduces the entire process to running a single command. All the relevant lists are generated automatically making the process easier and removing any chance for human error.
Next steps
Wiring the above automations to run sequentially would streamline the entire process to a single click of the button:
- Take a list of Gutenberg PRs as an input
- Create a Pull Request against
wordpress-develop as an output (example)
With the caveat that merge conflicts would still have to be resolved manually.
I’d love to inspire the next release squad to explore this during the 6.1 release cycle.
By simplifying these two large areas, I believe we can truly make the Tech Editor Release Lead The community member ultimately responsible for the Release. role mostly about the decision, communication, and creative work without so many repetitive tasks.
Props to Héctor Prieto (@priethor) and Grzegorz Ziółkowski (@gziolo) for their help in putting this post together.
#6-0-1, #6-1, #core, #core-editor, #gutenberg
