The WordPress coreCoreCore is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
Found a bugbugA 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.?Create a ticket in the bug tracker.
In the WordPress release cycle, feature freeze happens when the first betaBetaA 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 coreCoreCore 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 “enhancementenhancementEnhancements 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 GutenbergGutenbergThe 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/ 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 trunktrunkA 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:
According to recent stats at least 60% of these sites are rapidly updated to the newest version of the pluginPluginA 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.
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 TracTracAn open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..
New TicketticketCreated 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 candidateOne 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 bugbugA 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.
I realize that this proposal affects only a small part of the community, primarily frequent core contributorsCore ContributorsCore 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. https://core.trac.wordpress.org., 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.