WordPress 5.2 Schedule and Scope

With WordPress 5.1 RC1 being released, and trunk being reopened for work on WordPress 5.2, let’s discuss what the release schedule should look like, and what can be done in that time.

During the core chat earlier this week, I proposed a “late April” release date. This is primarily driven by the proposal to bump WordPress’ minimum PHP and MySQL version requirements, which suggested April as an initial target.

Proposed WordPress 5.2 Schedule

To give something a little more specific than “late April”, I’d like to propose the following key dates for WordPress 5.2.

  • Beta 1: March 14, 2019.
  • Release Candidate 1: April 10, 2019.
  • General Release: April 23, 2019.

Update: The schedule will be:

  • Beta 1: 21 March, 2019
  • Release Candidate: 17 April, 2019
  • General Release: 30 April, 2019

The end of April does have quite a few observed holidays to account for. The weekend of April 20/21 is Easter, the week of April 20-27 is Passover, and the weekend of April 27-28 is Orthodox Easter. The following week includes May Day, and is the week before the start of Ramadan.

I would like to propose April 23 as a reasonable compromise that isn’t an observed holiday for most people, and allows several days after the release for sites to test and upgrade.

Proposed WordPress 5.2 Scope

Given the timeframe, there are several projects in progress that would fit nicely.

Gutenberg

With the widgets to blocks being complete for Gutenberg 5.1, the Gutenberg work is ready to move into the next item on the 9 projects for 2019 list: the block directory. The way authors discover and use new blocks is shaping up to be an important part of the block editor experience, so join in the #meta and #core-editor channels to discuss this important part of our future infrastructure.

With the explosion of new blocks comes the need to manage them. There are a lot of plugins which add dozens of blocks, but authors may only need one or two of them. Being able to hide the ones they don’t use can only make the editing experience easier. The CoBlocks plugin recent introduced a Block Manager feature along these lines.

Additionally, the Gutenberg team have made more UX and performance improvements, which you can see in recent Gutenberg plugin releases.

Site Health Check

The Health Check plugin has been coming along nicely, and is looking like it will be ready to merge before beta 1. This is another of the 9 projects for 2019.

PHP Error Protection

While it missed WordPress 5.1, the core PHP team have been reworking the PHP Error Protection feature, and are on target for releasing it in WordPress 5.2.

Update Package Signing

Auto-updates are featured as two of the 9 projects for 2019, but to ensure these are completed in a safe and reliable fashion, there are a few steps to take beforehand. The first step involves implementing update package signing, which ensures sites have downloaded a valid update package. Once package signing has proven itself when running against WordPress 5.2.x releases, the next steps include improving the error detection and fallback mechanisms for the plugin and theme updaters, as well as making UI options available for enabling auto-updates.

Pending WordPress.org work and Systems approval, package signing could reasonably be ready for WordPress 5.2.

Everything Else

Of course, there’s always room for small enhancements and bug fixes. If there’s something you’re working on that could be ready for WordPress 5.2, please list it in the comments!

Proposed WordPress 5.2 Leads

@matt will continue his role as Release Lead, defining the scope of the release.

@chanthaboune will act as Release Coordinator, ensuring each of the WordPress 5.2 projects are communicating and running to schedule.

To avoid bottlenecks in the form of an unnamed Australian (who happens to be the author of this post), I’d like to propose we continue something that worked well during WordPress 5.0: a “feature release lead” role, with each of the projects having a point person to keep track of project status. For each of the proposed features (as well as any that are proposed in the comments), please put some thought into who could be a feature release lead, and include them in your comments.

#5-2