I’ve been around for a lot of core cycles—since the 4.x days, actually—and if there’s one thing I’ve learned, it’s that “Release Candidate” doesn’t always mean “clear skies.” The WordPress 7.0 Release Candidate phase has officially started, but we’ve hit a technical snag that reminds us why we have these phases in the first place. Specifically, a bottleneck in the branching process has changed the rules of engagement for the next few days.
The Branching Bottleneck and #64393
Usually, when we hit RC1, the 7.0 branch is carved out and trunk moves on to the next version (7.1-alpha). However, due to a technical issue identified in Trac ticket #64393, branching has been pushed back until RC2. This isn’t just a “wait and see” situation; it fundamentally changes how code gets committed to the WordPress 7.0 Release Candidate milestone.
Consequently, all commits to trunk now require a double sign-off by two core committers. In contrast to the usual “commit and move on” flow, this ensures that no breaking changes sneak in while we resolve the branching logic. If you’re a contributor, you’ll see the dev-feedback and dev-reviewed keywords being used heavily to manage this extra layer of scrutiny. Furthermore, you can check your current environment status using WP-CLI to ensure you’re testing against the right version.
# Check your current WordPress version and update to the RC
wp core update --version=7.0-RC1
wp core version --extraThe String Freeze Paradox
We are officially in a “hard string freeze.” This means no new strings are allowed unless they are critical, like the “About” page. However, there is a catch for the Polyglots team: strings won’t actually be available for translation until the 7.0 branch is physically created. Therefore, while developers are “frozen,” translators are effectively “blocked” until RC2 later this week. It’s a messy transition, but necessary for data integrity across locales.
If you’re tracking the development progress, you might find my previous deep dive on the WordPress 7.0 Roadmap useful for context on why some features were delayed even before this branching issue surfaced.
What Stays on the 7.0 Milestone?
For the remainder of this WordPress 7.0 Release Candidate cycle, the scope is very narrow. Only two things are allowed to move the needle:
- Regressions: Bugs introduced during the 7.0 cycle itself. If it worked in 6.7 and broke in 7.0, it’s a priority.
- Test Suite Expansion: We never stop writing tests. These can be committed at any time because they don’t impact the string freeze or the code logic itself.
Look, if this WordPress 7.0 Release Candidate stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Core Policy Takeaway
The delayed branching is a reminder that even the most mature software projects face race conditions and technical debt. Once RC2 drops and the branch is created, trunk will bump to WordPress 7.1-alpha, and the usual “wild west” of early development will resume. Until then, keep your PRs focused strictly on regressions and unit tests. Consistency is better than speed during an RC phase.
