Last week, WordPress Executive Director Josepha Haden Chomphosy opened a discussion on how many releases the project will aim for in 2022.

“Given that we have a release in January already, I wonder if we might be able to use 2022 to attempt four releases,” Haden Chomphosy said. She proposed three different release schedules:

• Quarterly releases: January, April, July, October
• Trimester-ly releases: January, May, September
• Known release and then evenly spaced targets?: January, May, August, November

When she brought it up in the #core Slack channel, a few contributors said they would like to see the project move towards more frequent releases. They were optimistic that it can be done, since a January release is already on the schedule.

Responses to the post on make.wordpress.org were markedly different. A few commented that they would be comfortable with a quarterly releases as long as they avoid major holidays. Several participants in the conversation have urged WordPress to slow down to two or three releases. Others suggested WordPress simply wait to release new features until they are ready, with no schedule. This particular suggestion makes it difficult for various stakeholders, like hosting companies, agencies, and WordPress product businesses, to plan effectively.

In 2021, WordPress released version 5.7 in March and 5.8 in July. A third major release planned for December was postponed due to critical blockers and decreased volunteer availability. A jump to four releases next year seems overly ambitious without a change in processes.

“Is it realistic to plan four releases for 2022 right after three releases per year plan was not fulfilled?” Oleg Kharchenko asked in the comments. “I don’t get what’s the benefit of having more releases just for the sake of number. It looks good in business reports but it has no real value for WordPress users as frequent releases lead to half-baked features which are hard to use.

“Also plugin and theme authors will have to put more time into testing instead of their product development. Finally, there are many tickets on Trac with ‘early’ keyword which are punted for years just because everybody is too busy to find time to include these tickets in the upcoming release, making the release schedule tighter would worsen this situation even more.”

Jessica Lyschik, a developer and an active member of the German WordPress community, said she would prefer two releases for the future.

“As several people already mentioned, planning more releases did not work out in the past, so why should it work now?” Lyschik asked. “5.9 got postponed to have refined features included so it can be actually used. The complexity of the new features is huge and trying to split that up in smaller releases is not something I see to work in the future.”

The roadmap for 2021 originally planned for four major releases but was scaled back to three in February. At that time Haden Chomphosy cited a lack of automation and the necessary personnel to execute the plan without risking contributor burnout and update fatigue.

WordPress core committer John Blackbourn commented on the discussion, urging Haden Chomphosy to elaborate on why she is proposing the potential of more frequent releases. He also requested she summarize the original list of challenges and needed changes and the progress that has been made towards improving them.

In a post titled “Why I Voted to Delay WordPress 5.9,” Anne McCarthy explained a few of the factors and blockers that caused the release to be postponed to January 2022.

“What I’d like to understand better is what are we going to do to make sure this doesn’t happen again?” WordPress 5.9 release lead Matt Mullenweg commented. “There could always be more polish, more bugs fixed, and I would challenge you to pick a year in the past decade that didn’t have its share of human issues. I’d like us to really understand and agree what went wrong, particularly in the first months of 5.9, and what we’re starting now to make sure 6.0 is effortlessly on time.”

McCarthy responded, citing the following reasons:

• lack of contingency plans around the interrelated features
• lack of clarity around scope for various individual features (particularly the browsing feature)
• lack of a comprehensive check in early enough ahead of feature freeze
• a need for more decision makers who have a high level view of where the work is headed

“Personally, I’d love to see the Go/No Go meeting overhauled to be less aspirational and more concrete as to where things stand as I think that’ll set the tone early enough in the release cycle to avoid some of these problems again,” McCarthy said.

A few of these challenges with 5.9 correspond to the items Haden Chomphosy identified in February as needing to change in order to make WordPress releases easier and more frequent: better testing, more seasoned core developers available with time focused on core, better handoff in design/dev iterations, and shifts in collective philosophies towards continuous development.

In the absence of a comprehensive 5.9 retrospective, it may be difficult to plan the next year’s release schedule based on the reality of what contributors experienced most recently. Moving to four major releases will be a tough sell after closing out a year where WordPress could not post three major releases. It will require significant changes to how the work is scoped and managed as it is in process. The topic will be up for discussion again during today’s weekly core dev chat at 20:00 UTC.