WordPress 7.1 Release Party Schedule: What Ships When

Every release cycle I get the same question from clients: “Is it safe to upgrade yet?” My answer has not changed in twenty years. Safety is not a date on a calendar. Safety is knowing what happened on that date, who was in the room, and what got tested before it ran on your site.

That is why I read release party schedules the moment they drop. They tell me exactly when each build lands, who is pressing the commit button, and where I need to be if something breaks. Skip that context and every upgrade feels like guesswork. Read it and you can walk into WordPress 7.1 with a plan.

The 7.1 schedule is now on the record. It is the kind of quiet, boring detail that lets a WordPress or WooCommerce agency sleep well while the industry hyperventilates about AI. Here is what the plan actually says, and how I would work around it.

What is actually new

On July 3, 2026, Benjamin Zekavica published the WordPress 7.1 Release Party Schedule on Make/Core. It confirms the final date the whole 7.1 squad has been targeting: August 19, 2026. Between now and then there are six checkpoints, each with its own party in the #core channel on Making WordPress Slack.

• Beta 1 — July 15, 2026 at 15:00 UTC, led by @krupajnanda
• Beta 2 — July 22, 2026 at 15:00 UTC, led by @krupajnanda
• Beta 3 — July 29, 2026 at 15:00 UTC, led by @benjamin_zekavica
• RC 1 — August 5, 2026 at 15:00 UTC, led by @benjamin_zekavica
• RC 2 — August 12, 2026 at 15:00 UTC, led by @krupajnanda
• Dry run and 24-hour freeze — August 18, 2026 at 15:00 UTC, both leads
• General Release — August 19, 2026, both leads

The stable roles behind those parties are worth naming, because they are the people whose calendars matter to you. @wildworks is the committer across every milestone. @joedolson holds the security seat. @sergeybiryukov sits at Mission Control, keeping the schedule and Trac aligned. That triangle — committer, security, coordination — is what turns a live Slack party into an actual, versioned release on WordPress.org.

The coordinators, Krupa Nanda and Benjamin Zekavica, are alternating on the release-lead seat under Anne McCarthy, who is the overall 7.1 release lead. That structure was set out in the 7.1 release squad announcement in mid-June, and the roadmap to 7.1 published on June 19 pins the same August 19 final. Nothing on the schedule surprises anyone who has been following along on Make/Core.

What is genuinely useful here is the way the parties are structured. Everything happens in one Slack channel. There is no in-person venue you have to travel to. Zekavica writes explicitly that “traveling and attending the event is not required to participate in the General Release Party” — you show up in #core, you test, you report back. The reference contribution guide from the 6.8 cycle lays out the drill: install Slack, join the channel about ten minutes early, have a local WordPress test site ready on the target build, run the testing checklist, and report results with a simple pass or fail marker.

Why it matters for WordPress and WooCommerce people

The 7.1 payload is not small. The roadmap commits to a persistent Guidelines feature for editorial rules, Notes upgrades with suggestion mode and emoji reactions, an AI Client that adds streaming generation and embeddings, three new core blocks (Playlist, Table of Contents, Tabs), responsive and pseudo-state styling controls in the Site Editor, and the React 19 upgrade returning behind an experiment flag. That is a lot of surface area for a store or an editorial site to absorb in one cycle.

Two dates in particular deserve to be on your team calendar. July 15 is when Beta 1 lands and trunk pins to the wp/7.1 branch — from that day forward, every dev note about a breaking change is aimed at you. August 5 is RC 1, which is when responsible plugin and theme authors are expected to have run a full pass against the release build. If your custom plugin or your WooCommerce integration only gets tested after August 19, you are the beta tester, and your client’s site is the staging environment.

There is also a practical benefit to the party structure itself: it is public. When a specific patch backfires between RC 1 and RC 2, you can trace it in Slack the same day. When something ships that surprises you, you can look at the commit list from that specific party and know exactly which contributor and which ticket were involved. This is the maturity story I keep telling clients — you get transparency baked into the workflow, not a vendor announcement two months after the fact.

For WooCommerce shops, the timing matters even more. WooCommerce 11.0 is scheduled for July 28, 2026, three weeks before WordPress 7.1. That gives you an unusually tight window where 11.0 lands on top of WordPress 7.0.x, then 7.1 arrives with React 19 experiments and new editor blocks. If you plan to be on both by end of August, you cannot leave testing to the last week.

What I would do (or not do) about it

Here is how I am running my own 7.1 prep, and what I am recommending to every client site under our watch.

• Book July 15 and August 5 in the team calendar. Beta 1 and RC 1 are the two windows where a competent agency earns its retainer. Everything else is smaller-scale.
• Stand up a 7.1 staging site by July 14. Use the WordPress Beta Tester plugin on a copy of production. Set it to bleeding-edge and point-releases. When Beta 1 drops it will pull automatically.
• Run your smoke checklist against every beta and RC. Not the full QA pass — that is unaffordable. Just the ten or fifteen flows that make you money: checkout, contact forms, the block templates you rely on, custom REST endpoints your headless clients hit.
• Read every dev note. The Field Guide will be compiled during the RC phase, but the individual notes appear throughout beta. Subscribe to the Make/Core RSS feed if you have not already.
• Do not treat the party as spectator sport. Show up in #core at 15:00 UTC on Beta 1 or RC 1. Test one thing. Report the result. You will learn more about how WordPress ships in one hour than in a year of reading recaps.

What I would not do: push a 7.1 upgrade to production on August 19 itself. There is nothing wrong with waiting for 7.1.1. There is a lot wrong with putting a fresh dot-zero release on top of a WooCommerce store that just took 11.0 three weeks earlier. Move to 7.1 on staging on release day, on production a week or two later, once the first field reports come in and the dust has settled.

Release parties are boring on purpose. That is the feature, not the bug — the more boring the party, the smoother the upgrade on your side.