WordPress 7.2 Planning Opens Before 7.1 Even Ships

🇹🇷 Türkçe: Bu yazının Türkçesini oku →

One release lands on Wednesday. The call for volunteers for the next one goes out the same afternoon. That is not sloppy scheduling — that is the sound of a release train that actually runs.

I have been shipping on this project long enough to remember when a WordPress major sat quietly for eight or nine months while everybody argued about whether the next one had a theme. That era is over. The pipeline now produces a major every three to four months, one dot release a week or two later, and a set of dev notes that the field guide collates into something you can actually plan a change window around. The interesting part of yesterday is not that WordPress 7.1 got its Release Candidate 3 — that was on the calendar. The interesting part is that Jeffrey Paul opened the WordPress 7.2 call for volunteers on the same day, with a proposed release date of December 9, 2026.

If you run WooCommerce stores or an agency roster, that December date is the one to write down. Not because 7.2 will land with fireworks. Because the change window you were quietly planning to leave alone in the run-up to Black Friday now has a WordPress major in it, and the sooner you know that the sooner you can decide what to do.

What is actually new

Two posts landed on Make/Core on August 12, both worth reading together. Jeffrey Paul’s WordPress 7.2 call for volunteers puts a proposed final release date of Wednesday, December 9, 2026, on the calendar and asks contributors to sign up for Release Lead, Release Coordination, Tech Leads, Triage Lead and Test Lead by August 28. That is roughly a four-month cycle from GA to GA, and it matches the cadence we have watched since 7.0 shipped on May 20 and 7.1 was pinned to August 19. The three-to-four-month drumbeat is now the schedule, not the exception.

Krupa Nanda’s WordPress 7.1 Release Candidate 3 post shipped hours earlier the same day, with more than ninety fixes since RC1 — 37 in the Editor and 57 in Core — and the hard string freeze now locked so translation work can proceed. Testing paths listed are the usual four: Beta Tester plugin, direct download, WP-CLI, or Playground. The RC1 announcement on wordpress.org/news still holds the anchor context, and Milana Cap’s 7.1 Field Guide is the one page to keep open if you have not yet.

The 7.1 release leadership on the 7.1 planning page — Anne McCarthy as Release Lead, Benjamin Zekavica and Krupa Nanda coordinating, Aki Hamano and Joe Dolson as Tech Leads — will roll off after August 19. Some of those names may reappear on the 7.2 team, some will not. That rotation is deliberate: the project treats release leadership as a term, not a job title. It is one of the quieter reasons WordPress has survived twenty-two years of contributors turning over.

What 7.2 will ship is not yet on the page. Jeffrey Paul explicitly points at the 7.1 roadmap format Anne Eza wrote in June and says the 7.2 planning page will follow the same shape once the team is confirmed. Expect it late August or early September, likely with a Gutenberg 24.x milestone attached and continued follow-through on Abilities API discovery, DataViews server-side registration, and the responsive-styles surface that landed in 7.1.

Why it matters for WordPress and WooCommerce people

December 9 is the date that changes your Q4. Most retainer plans I have seen for 2026 treat late November and early December as a code-freeze window — the annual “do not touch anything before Christmas trading” rule that keeps clients calm. A WordPress major landing on the second Wednesday of December falls squarely inside that window, and the honest answer is that most stores should not upgrade in the same fortnight.

That does not mean ignore 7.2. It means the plan is: watch it ship, read the dev notes, run it on staging in December, upgrade production in January. The stores that get burned every year are the ones that either upgrade blindly on release day or refuse to look at it until March. Neither is a plan.

The parallel to WooCommerce is close. Woo has been running the same governance discipline out loud under the Foundations initiative, most recently in the August Office Hours announcement from Brian Coords. Coordinated backports, calm advisories, on-time delivery of revised dates — that is what a working release train looks like, whether the letterhead says WordPress or WooCommerce. Both projects now telegraph their calendars far enough ahead that an agency can plan around them instead of reacting to them.

There is also a governance angle for the contributors on your team. If someone on your bench has been building against Abilities API filters, DataViews, or the responsive Global Styles surface, this is the window in which a Tech Lead or Triage Lead role on 7.2 is genuinely reachable. Two of the biggest names in this year’s release teams first showed up as triage volunteers. The path from “I filed a Trac ticket” to “I run the release” is shorter than the outside sees.

What I would do (or not do) about it

Here is the short version of what I am doing this week, in order.

• Put December 9, 2026, in the shared calendar as a WordPress 7.2 GA marker, with a matching January window pencilled in for the actual upgrade wave. Do not commit either date to a client yet — just claim the space so nobody else books over it.
• Finish the 7.1 pre-flight work you should already be doing. RC3 is where the branch narrows sharply, and if a regression on your specific stack is going to surface it will surface in the next week. Clone one representative site, install RC3 via the Beta Tester plugin, run the ten-minute smoke test (login, publish, cart, guest checkout, one refund, one CSV export) and file anything you find on Trac. This week is the last window in which a fix can still ride 7.1 GA.
• If you have a senior developer who has been quietly contributing to Gutenberg or Core Trac tickets, forward them the 7.2 call for volunteers and let them decide. Do not sign them up unasked. A Triage Lead role is a real time commitment (roughly 3–5 hours a week during a cycle) and it needs to fit around client work, not on top of it.

Two things I would not do. First, do not stack the 7.1 GA upgrade and the WooCommerce 11.0.x maintenance stream in the same change window on production stores next week. WooCommerce 11.0.1 shipped August 10 with its own 7.1 compatibility calibration per the developer blog, and both should have already landed on staging. Ship them to production in two separate windows, not one.

Second, do not build a client-facing dashboard that “tracks WordPress release dates” or “notifies you when a new major is announced.” The official news feed and the Make/Core RSS already do that better than anything you can wrap on top of them, and every layer of third-party tooling between you and the source is one more place that can go quietly wrong on the day it matters most. Read the primary source, take the note, keep the plan boring.

The story of yesterday is not the RC and it is not the volunteer post on its own. It is the two of them landing on the same day. That is a project that has learned to look at the next horizon before the current one clears. Version numbers change every four months now; the discipline behind them is what keeps them worth upgrading to.