WordPress lead developer Andrew Ozz has published a proposal for the addition of a new “gutenberg-merge” ticket type that would formalize the latitude Gutenberg contributors have been given for committing code after Feature Freeze during the release cycle.
Ordinarily, any new features and enhancements landing in the release are required to be committed before Beta 1 so they can be ready for testing. It used to be the case that tickets could be changed from “enhancement” to “task” right before Beta 1 as a rare exception for items that were not ready in time for beta and just needed a few more days to get committed.
“The intent was to allow another two or three days, not a week or two,” Ozz said. “This exception used to happen quite rarely, perhaps a few times per year.
“However lately this exception has become part of the standard release workflow. In recent years, it’s become common for 15 to 20 tickets for code coming from Gutenberg to be changed to tasks each release. The reason they are changed is not to give the developers a few more days to complete them. It is mostly to signify that they are going to be committed later.”
Ozz contends that because the Gutenberg feature plugin is used on more than 300,000 site, including WordPress.com, and because 60% of users rapidly update to the latest version, that any features and enhancements coming from Gutenberg have already been tested.
The comment section of the proposal is active with differing opinions. Several participants in the discussion did not agree that just because features are in the plugin does not mean that they have been adequately tested against the goals they were intended to achieve.
“Something that worries me about how this could work is, that currently the level of documentation for features that land in core have a higher standard than Gutenberg merges,” Core contributor Fabian Kägy said. “Once we approach the beta 1 time the documentation team goes through all the features that were merged in that cycle, making sure there are dev notes for any changes that might impact users / developers. If this deadline is shortened this also means that it may become harder to uphold this standard.”
Kägy also noted the challenges of plugin and theme developers testing their extensions against core in order to ensure compatibility with the latest version.
“With this changed workflow the actual amount of time where you know with a pretty large likelihood what features will be part of a given core release becomes shorter, making it more difficult to ensure compatibly with a release in time of the release,” Kägy said.
Core contributor Peter Wilson outlined two concerns with the proposal:
- by treating Gutenberg as a special case, it will increase the conflict between those who primarily work in the WordPress-Develop repository and those who primarily work in the Gutenberg repository,
- bypassing the feature freeze requirements for the editor goes against the contention that Core is Gutenberg and Gutenberg is Core.
Wilson said the late merging of Gutenberg features has “been a source of conflict for several years.”
“Bulk merges of Gutenberg features late in the cycle have also been an issue reported from both those who work primarily in the Gutenberg repo and those who work primarily in the WordPress-Develop repo,” he said. “For years incremental merges during the cycle have been advocated but never achieved per the comments in the linked post.”
Wilson also disagrees with the proposal’s assertion that features developed in the Gutenberg repository are better tested in the feature plugin, as the goal of the Beta and RC periods are to test the release as a whole.
“With Gutenberg as a plugin replacing core blocks with the plugin’s versions, testing the release as a whole doesn’t happen until after the editor changes merged in to WordPress-Develop,” Wilson said.
“It’s only once Gutenberg is merged in to WordPress-Develop that the unit tests start running on various hosting providers running the test suite in a range of environments.”
WordPress Core Committer Joe McGill encouraged the proposal’s authors to elaborate on the policies and expectations that will be applied to committing patches to tickets designated with the new ticket type.
“For example, should all of these commits be completed before RC-1, unless a bug is discovered during the RC period—and only the fixes discovered be committed, or are there other rules in play?” McGill said. “Personally, I still think that we should aim to have code for any major new feature merged before the Beta-1 milestone, regardless of whether it’s being tested in the Gutenberg plugin or not.”
The discussion is ongoing in the comments of the proposal. Although the proposed changes primarily affect core contributors, committers, and release leads, they also impact testers and WordPress’ plugin and theme developer community working to ensure compatibility ahead of a major release. Those who have feedback on how Gutenberg features are handled during and after “feature freeze” should jump in on the comments of the proposal.