Proposal: Updates to the WordPress Release Cycle

What is Feature Freeze

In the WordPress release cycle, feature freeze happens when the first betaBeta 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. version is released. “Feature freeze” means that development of new features and enhancements ends, and work continues on testing them and fixing bugs. They have to be ready for testing and committed to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. before the freeze, before Beta 1 is released.

Exceptions to Feature Freeze

Changing tickets from “enhancementenhancement Enhancements are simple improvements to WordPress, such as the addition of a hook, a new feature, or an improvement to an existing feature.” to “task” right before Beta 1 is an exception that has been used for many years. It was strictly for new features and substantial enhancements that weren’t ready in time for beta, and needed a few more days to get completed and committed (thus delaying their testing to Beta 2). 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 GutenbergGutenberg 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. 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.

Why Gutenberg Merges Are Different

The new features and enhancements coming from Gutenberg have already been tested. I think everybody would agree that testing in Gutenberg releases is quite better and more efficient than testing in core trunktrunk 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. beta releases:

  • The Gutenberg plugin is used on over 300,000 sites, including some huge sites like
  • According to recent stats at least 60% of these sites are rapidly updated to the newest version of the pluginPlugin 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 Plugin Directory or can be cost-based plugin from a third-party.

So the new features and enhancements that are in a Gutenberg release are being tested on at least 180,000 sites, and by well over 180,000 users, mostly in a production environment. For comparison, there are usually only a few thousand installs for beta releases.

It seems the WordPress release workflow should adapt to these changes in the development process: synchronizing code between two repositories, new Gutenberg releases every two weeks, etc. Using the old “change enhancements to tasks” exception shouldn’t be necessary for code that has already been released and tested in Gutenberg. However, it still makes sense for feature development that happens on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..

New Ticketticket Created for both bug reports and feature development on the bug tracker. Type: Gutenberg merge

I’d like to propose to stop changing tickets from “enhancement” to “task” before beta when the code has been sufficiently tested in Gutenberg.

Based on the above plugin installation stats it seems that a sufficient time for testing in a Gutenberg release would be one week. Ideally, all code coming from Gutenberg would meet this criteria, regardless of the WordPress release cycle stage (alpha, beta, or RCrelease 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).). An exception would be when committing bugbug 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 that can be tested simultaneously in Gutenberg and core beta/RC releases.

To easily distinguish these tickets maybe a new ticket type can be introduced. Perhaps “Gutenberg merge” or “Gutenberg sync”? Alternatively, the existing gutenberg-merge keyword could be used, although it would be somewhat less noticeable.

For example:


I realize that this proposal affects only a small part of the community, primarily frequent core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac., committers, and release leads. But I still think it is best to propose it here in the interest of openness, and for documentation purposes.

If you have thoughts about how new Gutenberg features are handled with regard to “feature freeze” during the beta stage of the release cycle, please share them in the comments below.

Thanks @peterwilsoncc, and @ironprogrammer for the review and suggestions.

#proposal, #release-process