The WordPress 7.0 release process is in its final phase now. If you’ve been around since the 4.x days, you know a major version launch is a logistics marathon, not “another update.” Most of the standard advice skips what actually happens behind the scenes in the last 24 hours before launch, and if you run enterprise sites or complex WooCommerce builds, you can’t afford to find out on May 20th.
The 24-hour code freeze and why it matters
The WordPress 7.0 branch goes into a mandatory code freeze after the “Dry Run” on Tuesday, May 19, 2026. The release squad locks the source code, and nothing changes unless someone finds a real “blocker.” If a critical bug turns up, the clock resets: the Dry Run happens again and the 24-hour freeze starts over. This is usually when “race conditions” in legacy plugins show up.
Release timeline
- Dry Run: Finished Tuesday, May 19, 2026, at 21:00 UTC.
- Code Freeze: In effect now (no source code changes allowed).
- Release Party: Wednesday, May 20, 2026, at 17:00 UTC in #core Slack.
Testing during the WordPress 7.0 release process
I’ve watched plenty of developers skip testing on less common server setups like IIS. Part of the WordPress 7.0 release process is checking the ZIP packages on as many environments as possible. And since WordPress 7.0 sets a PHP 7.4 floor and recommends PHP 8.3+, you need to test your upgrade path on older environments too.
If you want to get ahead of it, run the RC4 or RC5 packages now. WP-CLI will pull the latest candidate for testing without getting in the way of your normal work.
# Update to the latest WordPress 7.0 Release Candidate via WP-CLI
wp core update --version=7.0-RC4
# Verify the version after update
wp core versionFlows to check
Test these scenarios before the release party starts. I’ve seen multisite networks break during minor core updates because of stale transients, and a jump to 7.0 carries more risk than that. Check that the files listed in $_old_files really get removed during the upgrade. If they stick around, they can conflict with the new API hooks in ways that are hard to predict.
- Fresh Installs: Manual, WP-CLI, and one-click installers.
- Multisite: Subdirectory and subdomain network upgrades.
- User Flows: Publishing blocks, commenting, and switching site language.
- Plugin Compatibility: Especially plugins that hook into the editor or admin UI.
For more on what this version brings, see my breakdown of WordPress 7.0 AI integration and why the RC5 testing phase mattered so much for stability.
If the WordPress 7.0 release process is eating your dev hours, I can take it off your plate. I’ve been wrestling with WordPress since the 4.x days.
What maintainers should do now
The WordPress 7.0 release process is built for stability, but it depends on people reporting what they find. If you hit a bug during the freeze, report it in #core Slack right away. Major releases have a lot more steps than small updates, and fixing a last-minute issue takes time. Don’t wait for the May 20th “Release Party” to learn your custom blocks are broken.
The Official Major Version Release Process has the full checklist the core squad uses.
