82. WordPress is dead. Long live WordPress.

·

WordPress 6.8 is going to be the last version for a season… at least until the arrival of 2026, suggesting an annual release cycle.

Remember that you can listen to this program from Pocket Casts, Spotify, and Apple Podcasts or subscribe to the feed directly.

Program transcript

Hello, I’m Alicia Ireland, and you’re listening to WPpodcast, bringing the weekly news from the WordPress Community.

In this episode, you’ll find the information from March 31th to April 6th, 2025.

On March 27, there was a meeting of 30 people who contribute to and manage the open source WordPress project, where it was noted that in the last 6 months, the tickets for Gutenberg and the WordPress core have been flat, although the closing work has dropped since the release of WordPress 6.7 at the end of 2024.

This led to the meeting focusing on whether the number of WordPress releases should be reduced, from the usual 3 releases per year to only 1.

The article refers to some points in favor and against this change, although in these days when there is so much noise and fake news, data verification is needed to clearly see that most of the advantages presented are not true.

Regarding the reduction of workload and coordination, it is true that a slower release pace would relieve the current pressure on contributors and teams, which is especially relevant at a time when availability and sponsored hours have decreased significantly.

As for the improvement in documentation and infrastructure, this point is realistic, since one of the current challenges is precisely the incomplete documentation and outdated infrastructure, something that a slowdown could clearly improve.

Regarding the greater automation of processes, it is plausible and logical that less pressure would allow time to be invested in automation, a need already expressed by the core team on several recent occasions. However, it must be noted that the ones who can perform these tasks are the people from Automattic who are currently not contributing to the project.

Still, the anxiety in the face of larger releases does match reality, especially for a community that has grown accustomed to small, frequent changes, where substantial modifications can raise concerns about compatibility and stability.

That allowing larger features to be included—avoiding versions that only contain fixes—is technically true, but the recent decrease in contributions, partly due to the legal conflict between Automattic and WP Engine and its side effects, could make it difficult in practice to achieve major releases due to a lack of resources.

It is mentioned that there is alignment with the pace of organizations like eBay or Airbnb, and although some large companies adopt slow cycles for quality, the context of WordPress, an open community project, is not entirely comparable to large private companies.

A main focus would be on concentrating on canonical plugins and individual components, which, while positive, does not necessarily guarantee success, as it would depend greatly on how the project is organized and on the real support each component or plugin receives in times of crisis like the current one.

Regarding the idea that fewer releases may slow down feedback—although this is theoretically true—the recent reality shows that feedback cycles are already slow due to the decrease in contributions, regardless of the release pace.

There would be a greater difficulty in justifying sponsored time and resources, which is partially false since there is already difficulty justifying sponsorships, and it is likely that this situation will worsen even more if the perception arises that the project is losing speed or relevance due to internal conflicts.

And regarding the notion that there will be less visible momentum towards the project’s goals, that is something that is already happening. The reduction in contributions and the ongoing legal battle have affected the external perception of the project, so the real problem already exists, regardless of whether a slower cycle is adopted or not.

What is the proposal?

Following the discussions, it has been decided that WordPress 6.8 will be the last major version of WordPress during 2025. Although there will be no major releases until 2026, the Gutenberg plugin will continue receiving minor updates every two weeks, as it currently does, which implies that if improvements in the editor—both for Site and Content—are desired, it will have to be installed to enhance editing.

Furthermore, minor versions of WordPress will continue to be published throughout the rest of the year, which will include small improvements and necessary fixes, while maintaining the current rule of not adding new files in these minor releases.

Regarding the official plugins, canonical plugins, maintained by the community—such as preferred languages, two-factor authentication (2FA), and performance-related plugins—allow for incorporating and updating functionalities without depending on the annual major release. Two key areas for improvement were identified: effective gathering of feedback by seeking new ways to collect more meaningful comments than the simple metric of active installations, possibly including telemetry to better understand usage and the perceived value by users, something that will need to be examined in detail as it could violate certain international regulations, such as the GDPR. This would be accompanied by better promotion and visibility of these plugins, either through posts on the official blog, mentions at important events (such as State of the Word), or better utilization of underused spaces in the admin panel, such as the “Tools” section.

Another important task, which has been discussed for many years, is the urgent need to improve the management of the enormous current backlog with more than 12,000 tickets, moving the majority of them to minor releases, regardless of the main cycle. It is also proposed to close or postpone old or irrelevant tickets using the resolution “maybelater,” something that previously generated debate regarding who decides what is important or not in the project. Thus, since a large backlog negatively affects the external perception of the project’s quality and maintainability, efforts will be made to reduce this perception through more efficient management.

In addition, various areas to be improved were mentioned to strengthen the development and maintenance of the project, such as placing greater emphasis on testing by promoting the extended use of beta and nightly versions through educational initiatives and specific collaborations with hosting providers.

Reviewing the flow between SVN/GitHub repositories is also on the table, to explore ways to simplify and optimize the current release processes for both the core and Gutenberg. This could lead to reducing the release frequency of Gutenberg plugin updates to once a month if the volume of changes continues to decrease.

Clarifying the responsibility of maintainers and giving greater autonomy to teams and components is another focus. This would involve defining clear expectations for volunteers responsible for components, motivating them to participate more consistently, and having the Release Squads act as facilitators, thereby driving greater autonomy and active participation among the project’s individual teams and components.

Regarding accessibility and other standards and regulations, it is necessary to clarify which accessibility requirements are mandatory and which additional practices are desirable but not blocking.

And finally, there is a need to involve more non-technical profiles, as several have left the community in recent months. Additional channels should be established to actively engage collaborators with profiles other than development, such as design, testing, or product.

Undoubtedly, it is an interesting and important moment for the project, while outside the official channels alternatives to the project’s governance are being prepared, now that it seems that, since the departure of the former executive leadership of the project, there is no defined roadmap.

And with the second release candidate of WordPress 6.8, and with the third still pending, the final version of this new branch of WordPress—which appears to last a few months—will be released on April 15.

And in the monthly Core summary, we can see how India and other Asian countries continue to grow in contributions to the WordPress core, while others, such as the United States, continue to decline.

On this occasion, in the final stretch of the launch of a new version, when contributions typically increase, in March the number of people who contributed has been reduced to fewer than 200 even though the number of open tickets has increased.

The Community team has announced an update that allows volunteer badges to be awarded on profiles to those who collaborate at WordCamp events. These badges aim to publicly recognize the importance of volunteer work, highlighting those who contribute to the organization of these global WordPress conferences.

Previously, only organizers and speakers received badges on their profiles, but now volunteers will also be able to display this official recognition. The badges will be assigned by the organizers of each WordCamp through the event’s dedicated website.

WordCamp Europe 2025 is approaching and the schedule is already available, which, as in previous years, will feature a first day of Contributor Day followed by two days of talks and workshops.

The specific topics of the European Union, on accessibility and cybersecurity, stand out in the schedule, which is composed of 52 speakers from 23 countries.

And finally, this podcast is distributed under a Creative Commons license as a derivative version of the podcast in Spanish; you can find all the links for more information, and the podcast in other languages, at WPpodcast .org.

Thanks for listening, and until the next episode!

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *