On March 27, 2025 nearly 30 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. committers, project leaders, and core team members gathered to discuss the release cadence and if there is a need to change it. The impetus for this conversation is due to organizations cutting back on the number of hours they are donating towards contributing to WordPress.

Attendees: @matt, @desrosj, @jorbin, @timothyblynjacobs, @davidbaumwald, @jjj, @clorith, @jeffpaul, @joemcgill, @kadamwhite, @fabiankaegy, @4thhubbard, @adamsilverstein, @swissspidy, @whyisjake, @spacedmonkey, @eidolonnight, @matveb, @audrasjb, @mamaduka, @karmatosed, @sergeybiryukov, @westonruter, @ryelle, @flixos90, @williampatton, @poena, @johnbillion, @joedolson.

An assessment of core team activity shows the number of both 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. https://wordpress.org/gutenberg/ tickets and Core TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets remaining nearly flat over the last 6 months. However, the volume of new features being worked on inside the Gutenberg repository has plunged since January. In light of this information, the discussion focused on if the current release cadence should be reduced.

Numerous pros and cons were discussed.

The pros included:

• Aligns WordPress with the release cadence that is becoming en vogue amongst some large organizations such as eBay and Airbnb
• Can use this change to signal an intentional reset and focus on quality
• Allows for greater focus on canonical plugins and on individual component roadmaps, which can be iterated on and shipped independent of major releases.
• Slowing down helps allow for documentation and any needed infrastructure improvements.
• Allow for each release to contain larger features and enhancements and not be “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. fix only” releases.
• Reduces the workload and coordination overhead for contributors, systems team, and release leads.
• Allows for work to further automate release processes, making future releases quicker and less manual.

The cons and risks discussed included:

• Fewer releases can slow down user feedback loops for new features.
• Slower cadence can lead to contributors not being able to see their work published or feel recognized as quickly.
• Makes it harder for changes that we may want to roll out over multiple releases
• Harder to make changes such as coding standard updates that can lead to a release branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". and 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. changing.
• Potential for anxiety over larger releases from users, site owners, and anyone else applying updates.
• Potentially harder for organizations to justify time and resources for sponsored contributors.
• Less visible momentum towards the project’s overall goals, possibly perceiving the project as stale.
• Care needs to be taken to preserve the culture and trust built in auto-updates that the project has worked hard to build over the last decade.

Proposed Focus Areas

The conversation moved to discussing where contributors could effectively focus their efforts in the project should the release schedule shift to just one release per year.

Canonical Plugins

Community maintained canonical plugins such as Preferred languages, 2FA, and the Performance Team’s suite of plugins are a great way to ship features and iterate without requiring a major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. of WordPress itself. There were two main improvements that need to be addressed to make them more effective.

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.

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.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ News blogblog (versus network, site), mentioning them in presentations such as State of the WordState of the Word This is the annual report given by Matt Mullenweg, founder of WordPress at WordCamp US. It looks at what we’ve done, what we’re doing, and the future of WordPress. https://wordpress.tv/tag/state-of-the-word/., and possibly the currently barren Tools page in the WordPress adminadmin (and super admin).

Backlog Management

• Going through the backlog of ~13,000 total tickets on Trac and Gutenberg’s GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/ repository is something that can be done independent of major releases.
• The majority of bugfixes can be shipped in minor releases.
• ‘maybelater' resolution exists for a reason and should be used more often. Discussion can always continue on closed tickets.
• A large backlog can damage the perception of project quality and maintainability.
• All numbers are just numbers in isolation. They need to be considered in context with surrounding factors.

Miscellaneous

• Look for ways to encourage wider testing of 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./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). releases, and even nightly builds through the initiatives like the Host Tests, and educating developers of the possible advantages of continually using trunk for testing.
• Reevaluate the Core SVNSVN Subversion, the popular version control system (VCS) by the Apache project, used by WordPress to manage changes to its codebase./Gutenberg repository setup to find ways to streamline the release process.
• With overall fewer features being built in the Gutenberg repository, shifting 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 WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party.’s release cadence to once a month may make sense. Though the current cadence is manageable, mostly automated, keeping this consistent is preferable if volume allows.
• Encourage component maintainers to be more active by clarifying the responsibilities and expectations of volunteering in that capacity.
• Release squads should primarily coordinate, encouraging broader autonomy and participation by components and various Make WordPress teams.
• For accessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility), clarify the differences between mandatory compliance (WCAGWCAG WCAG is an acronym for Web Content Accessibility Guidelines. These guidelines are helping make sure the internet is accessible to all people no matter how they would need to access the internet (screen-reader, keyboard only, etc) https://www.w3.org/TR/WCAG21/.) and what non-blocking aspirational best practices are.
• Explore faster release models once shortcomings in tooling are addressed.
• Get better at involving contributors with non-development skill sets (e.g., design, testing, product) in more ways.

Summary

In light of these discussions, the current plans of project leadership are for 6.8 (due this month) to be the final major release of 2025. Gutenberg releases will continue on the current every two week schedule and minor releases will take place as needed throughout the year. Minor releases will continue and happen as necessary with a more relaxed barrier for inclusion of enhancements, but the “no new files in minor releases” rule should continue to be followed.

Based on this productive conversation, a decision was made to organize these calls on an ongoing basis starting with a quarterly cadence. I will ensure to schedule accordingly.

Props to @jorbin and @desrosj for collecting the summary and writing this post.

#core-committer-meetings, #core-committers