WordPress 7.0 just moved into the second phase of its WordPress 7.0 Release Candidate cycle, and if you’re a developer tracking core, things just got a lot more restrictive. RC2 dropped on March 26, and with it, the “trunk” branch has officially moved on to version 7.1-alpha. If you’ve been building against trunk thinking you’re testing the 7.0 release, it’s time to pivot your local environment.
The Branching Dance: Trunk vs. 7.0 Branch
In the world of core development, once we hit this stage, trunk becomes the wild west for the next major version. For the WordPress 7.0 Release Candidate, this means 7.0 now lives in its own stable branch. If you are testing for production stability, you need to be following the 7.0 branch specifically.
I’ve seen plenty of agencies get burned because their CI/CD pipelines were pulling from trunk during the RC phase, accidentally introducing 7.1-alpha features into a 7.0 environment. Specifically, you want to ensure your testing environment is pinned to the correct branch. You can use WP-CLI to switch easily:
# Switch to the 7.0 branch for final testing
wp core update --version=7.0-RC2Strict Stability: Backporting and Sign-offs
Stability is now the only priority. Any production code that needs to move from trunk to the 7.0 branch now requires a double sign-off by two core committers. This isn’t just bureaucracy; it’s a safeguard against regressions. Contributors must use the dev-feedback keyword in Trac to trigger a review, and only once dev-reviewed is added can the code be merged. This process ensures that no “cowboy commits” break your client sites on release day.
Furthermore, we are under a hard String Freeze. Unless it’s a critical bug in something like the “About” page, no new translatable strings are allowed. If you’re building plugins that rely on core strings, don’t expect them to change until the 7.1 cycle begins. For more on this, check out the official backporting docs.
What Stays on the 7.0 Milestone?
At this point in the WordPress 7.0 Release Candidate phase, the milestone is essentially locked. Only two types of tickets are permitted:
- Regressions: Bugs introduced specifically during the 7.0 development cycle. If it’s a bug that has existed since 6.5, it’s likely going to wait for 7.1.
- Test suite expansion: You can always add more tests. In fact, you should. Tests don’t affect the code freeze and are vital for verifying the stability of new features like the real-time collaboration tools we’ve been tracking.
I previously discussed how RC1 introduced major AI features, and now we are seeing the refinement stage. The focus has shifted from “what can it do?” to “how can we ensure it doesn’t break?”
Look, if this WordPress 7.0 stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
Final Takeaway for Developers
The message from the core team is clear: stop adding, start polishing. If you have open tickets on the 7.0 milestone that aren’t regressions, expect them to be punted to 7.1. Ensure your local environments are updated, respect the string freeze, and coordinate any “must-have” changes in the #7-0-release-leads Slack channel. Now is the time to ship stability, not experiments.
