Normally, any new features and enhancements landing in the release are required to be committed before Beta 1 so they can be ready for testing during the beta phase. It used to be the case that tickets could be changed from “enhancement” to “task” right before Beta 1 as only a rare exception for items that were not ready in time for beta and just needed a few more days to get the go-ahead to be committed.
“The intent was to allow another two or three days, not a week or two. 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 said
Ozz claims that because the Gutenberg feature plugin is used on 300,000+ sites, 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 varying opinions. Several of the 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. 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.”Core contributor Fabian Kägy said
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
- 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.”
Wilson also disagrees with the proposal’s statement 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 across many sites with different configurations.
“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? 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.”McGill said