WordPress 7.1 will ship on August 19, 2026 - the final day of WordCamp US in Phoenix. It is the middle release in a three-release year: 7.0 on April 9 (Contributor Day at WordCamp Asia), 7.1 on August 19 (WordCamp US close), and 7.2 around December 8 (State of the Word week). The proposal, published by core committer Jonathan Desrosiers in December 2025, returns the project to three majors per year after a two-release 2025, and continues the live-on-stage release model that 6.9 normalised in December 2025.
The Architectural Shift Is the Pinning, Not the Cadence
Three releases a year is not new - it is the long-running WordPress baseline. The new thing is that each date is now anchored to a flagship event, not to a feature-readiness signal. Beta 1 and RC dates are reverse-engineered from the event: 7.1 needs Beta 1 on July 1 and RC1 on July 29 to be safe to live-release on August 19. The release squad now optimises for hitting the calendar, not for the train leaves when the train is full.
This is a meaningful change in incentive structure, even though nobody in the proposal frames it that way. Calendar-driven releases trade off in a specific direction: features that miss the gate slip to the next major (four months later), and features that almost make it ship with rougher edges than they would have under a “we’ll ship when it’s ready” regime. Both behaviours are visible already in shops that practise time-boxed releases - Chrome, Firefox, the Linux kernel - and both are workable, as long as downstream consumers know which mode they are in.
What It Means for Sites and Plugins
For site owners, the practical effect is that upgrade windows are now predictable a year out. If you maintain a non-trivial WordPress fleet, you can put April 9, August 19, and December 8 on the calendar today and budget testing capacity around them. The minor-release stream (1–3 per major) still happens between these dates, but the breaking surface shifts on the predictable schedule.
For plugin authors, the change is sharper. A four-month major cadence means a hard upper bound on how long deprecations can hang around before they become removals, and a strict window in which to ship compatibility updates before a major lands on a million sites at once. If your plugin’s CI does not test against trunk weekly, the August 19 release is the deadline by which that gap closes. It is the same operational discipline that blocking gates enforce in content pipelines - make the schedule a system constraint, not a human aspiration.
The Quiet Caveat in the Proposal
Desrosiers explicitly notes that “there is no requirement to travel in order to be on a release squad” - communication stays in Slack. That matters because tying releases to events risks centring the project on whoever can fly to Asia, Phoenix, or the State of the Word venue. The clarification keeps the contributor pipeline open even when the marketing moment sits on a stage.
The 7.2 December date is also flagged as the least flexible of the three, because Black Friday / Cyber Monday and year-end holidays compress the testing window. Expect that one to be the canary for whether event-pinning survives its first real schedule conflict.
The Short Version
WordPress 7.1 on August 19 is not just a date - it is the second proof point for a release model where the calendar drives the ship, not the readiness of the diff. If you run WordPress at scale or write plugins for sites that do, your 2026 upgrade plan effectively writes itself today.