With WordPress 5.1 RC1 being released, and trunk 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. 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 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: March 14, 2019. Release 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). 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 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/
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 Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. 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 User experience 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 The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher Error Protection
While it missed WordPress 5.1, the core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 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 and theme updaters, as well as making UI User interface options available for enabling auto-updates.
Pending WordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ work and Systems approval, package signing could reasonably be ready for WordPress 5.2.
Of course, there’s always room for small enhancements and bug 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. 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 The community member ultimately responsible for the Release., 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.