General WordPress 6.8, due later this month, will be the final major release of 2025

[Cpvr]

Automatic plans to launch Wordpress 6.8 later this month, which will be their final major release for this year.​

​

Dotorg Core Committers Check In​

On March 27, 2025 nearly 30 corecommitters, 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.

An assessment of core team activity shows the number of both Gutenberg tickets and Core Trac 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 “bug 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 branch and trunk 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 release 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.org News blog, mentioning them in presentations such as State of the Word, and possibly the currently barren Tools page in the WordPress admin.

Backlog Management

• Going through the backlog of ~13,000 total tickets on Trac and Gutenberg’s GitHub 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 beta/RC 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 SVN/Gutenberg repository setup to find ways to streamline the release process.
• With overall fewer features being built in the Gutenberg repository, shifting the plugin’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 accessibility, clarify the differences between mandatory compliance (WCAG) 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.

Source: https://make.wordpress.org/core/2025/04/04/dotorg-core-committers-check-in/