WordPress project leaders recently discussed how to proceed due to concern that organizations have dramatically cut back on the number of hours donated to contributing to WordPress. They decided that WordPress 6.8 would be the final major release of 2025 and that minor core releases will continue as needed.
While no formal commitment was made to future major releases after 2025, it kind of implies that future major releases are limited to one per year as long as the current contributor levels remain at this low level.
However that’s not for certain and it went unstated and prompted one of the contributors to ask the question in one of the comments:
“Is the new release cadence one major release a year now, or is that just for this year?
If getting users to wait a year for major updates, can I suggest some work towards an open road map so people can at least see what they are waiting for and in an ideal world, where resources are limited, vote on said features to help prioritise what the community wants from WordPress.”
Gutenberg & Core Trac Tickets Remain Flat
Gutenberg and Core Trac ticket volumes remained flat for the past six months, which means that the total number of tickets (number of unresolved issues) remains essentially the same, signalling stagnation in development as opposed to forward momentum.
New feature development in Gutenberg has declined sharply since January, which means that the creation of new blocks, capabilities, and user experience improvements has also slowed. This is cause for concern because a drop in new feature development indicates that the editor is not gaining new capabilities as quickly as it was in previous months, resulting in fewer enhancements, fewer innovations, and potentially less progress toward the long-term goals of the block editor project.
Work On Release Automation
One of the benefits discussed for slowing down the pace of development is that it frees up time to work on release automation, which means automating parts of the development. What exactly that means is not documented.
This is what the documentation says about it in the context of a benefit of slowing down the pace of development:
“Allows for work to further automate release processes, making future releases quicker and less manual.”
Focus On Canonical WordPress Plugins
It was decided that focusing on WordPress.org developed plugins, called canonical plugins, offered a path forward to improving core and adding features to it outside of contributions to the core itself. The canonical plugins discussed are Preferred Languages, 2FA (two-factor authentication), and Performance tools.
A long-running issue about the canonical plugins discussed at the meeting is the lack of user feedback about their canonical plugins, noting that the main source of feedback is when something breaks. The only other user feedback metric they have to work with is active installations, which doesn’t tell them anything about how users interact with a canonical plugin feature or how they feel about its usefulness and usability.
The documentation notes:
“First is the need for better means to collect user feedback. Active installs is currently the only metric available, but doesn’t provide enough value. Does a user actually interact with the feature? In what ways? Do they feel it’s valuable? Feedback is mainly received from users when something breaks. There was agreement to explore telemetry and ways to establish meaningful feedback loops within canonical plugins.”
Another issue with canonical plugins is that they’re not widely promoted and apparently many people don’t even know about them, partly because there’s no clear way for users to discover and access them.
They wrote:
“The second improvement needed is promotion. It’s often not widely known that canonical plugins exist or that they are officially maintained. Different ways to raise awareness about canonical plugins will be explored, including posts on the WordPress.org News blog, mentioning them in presentations such as State of the Word, and possibly the currently barren Tools page in the WordPress admin.”
That issue was echoed in the comments section by core contributors:
“Can you post a link so I can view all the canonical plugins please?
Is it the random selection under the dotorg user account?
https://profiles.wordpress.org/wordpressdotorg/#content-pluginsOr is it the six plugins listed as ‘beta’?
https://wordpress.org/plugins/browse/beta/”
“Also agree with the other commenters and the post that canonical plugins are woefully under promoted. As a developer and WordPress professional they are rarely on my radar until I stumble upon them. Is there even a link to them in the repository where we can view them all?”
Backlog Management
Contributors were encouraged to continue to work on clearing the backlog of around 13,000 tickets (open issues or feature requests) in both the Core Track and Gutenberg repository. Minor releases can continue with bugfixes.
Final Decisions
The final decisions made are that WordPress 6.8 will be the final major release of 2025. Gutenberg plugin releases will continue every two weeks and minor core releases will continue throughout the year, as needed, with a more relaxed pace for including enhancements. However, the rule of “no new files in minor releases” will still be followed. The project will begin quarterly contributor strategy calls to keep discussions going and adapt as needed.
Read the official documentation of the meeting:
Dotorg Core Committers Check In
Featured Image by Shutterstock/Tithi Luadthong
