A client called us in a panic last week. Their e-commerce launch had stalled because a hotfix for a payment gateway integration would not deploy, and the release manager was at the end of his rope. When we dug in, the cause was awkward: they had pushed the fix during what they assumed was a routine maintenance window, and it landed right in the middle of the WordPress 6.9 Release Candidate phase.
This is not a rare edge case. Once WordPress reaches Release Candidate (RC), what you are allowed to commit changes sharply. Ignoring the WordPress Release Candidate Policies is how patches get rejected and deadlines slip. So it is worth knowing what RC actually means and how to work within it.
Understanding the WordPress release candidate policies
Once a version enters RC, the core team shifts to stability and final polish. It is not the time for new features or big refactors; the focus is on locking things down for a clean public release. The core team spells this out clearly, as in this note at make.wordpress.org/core, but the message often gets buried in day-to-day work.
The string freeze: don’t break translations
One of the first things to land is the “string freeze,” which matters a lot to the Polyglots team that translates WordPress into hundreds of languages. Add a new string during RC and you stall their work, which can delay translations for the whole release. My client’s fix was a small text change in an error message, and it introduced a new string. I figured one line was harmless. It was not, and it held things up.
The rule is simple: no new strings. You can remove or duplicate existing ones, but you cannot add any. If a string is buggy and cannot be translated properly, take it to the Polyglots team leadership instead of fixing it yourself.
<?php
/**
* Function to display a notice.
*
* @param string $message The message to display.
*/
function bbioon_display_admin_notice( $message ) {
if ( ! current_user_can( 'manage_options' ) ) {
return;
}
// BAD: Adding a new string during String Freeze
// echo '<div class="notice notice-error"><p>' . esc_html__( 'bbioon: A new critical error has occurred!', 'bbioon-textdomain' ) . '</p></div>';
// GOOD: Using an existing string or ensuring no new ones are introduced
echo '<div class="notice notice-error"><p>' . esc_html__( $message, 'bbioon-textdomain' ) . '</p></div>';
}
// Example usage
// bbioon_display_admin_notice( 'An existing error message.' );
?>Tickets and the 6.9 milestone: what gets in?
During RC, only two kinds of tickets make it onto the milestone:
- Regressions: bugs introduced during the current 6.9 development cycle.
- Test suite expansion: tests can always be committed, since they improve stability without changing functionality.
If your “urgent fix” is not a regression, it probably will not make it in. My client’s payment gateway bug was a regression from the beta phase, so it qualified. Anything else, whether a new enhancement or a refactor, waits for WordPress 7.0-alpha, and the trunk for that is already open.
Backporting commits: the double sign-off
Even for eligible fixes, landing code in the RC branch (here, the 6.9 branch) is not a plain commit. Any production code needs a double sign-off from two core committers. You add the dev-feedback keyword to request the second review, then dev-reviewed once it is approved. It puts more eyes on the change so nothing new slips in right before release. We nearly skipped it, assuming our patch was simple enough, and that second review saved us.
<?php
/**
* Filters a critical bug fix for bbioon.
*
* This function should only be used for regressions during RC phase
* and requires double sign-off.
*
* @param bool $status Current status.
* @return bool Modified status.
*/
function bbioon_fix_critical_bug( $status ) {
// Implement the actual bug fix logic here.
$status = true; // Example fix.
/**
* Filters the status after a critical bug fix.
*
* @param bool $status The status after the fix.
* @since 1.0.0
*/
return apply_filters( 'bbioon_after_critical_bug_fix', $status );
}
add_filter( 'bbioon_critical_bug_status', 'bbioon_fix_critical_bug' );
// This commit would need 'dev-feedback' and 'dev-reviewed' in the commit message
// Example commit message: "FIX: #12345 Critical payment regression in 6.9 RC. dev-feedback dev-reviewed"
?>What this means for your work
The RC phase asks developers for a different mindset. It is not business as usual. Watch the string freeze, know which tickets are accepted, and follow the double sign-off for backports. These rules exist to keep WordPress stable for the millions of sites that run it, and trying to shortcut them usually creates more work, not less. Plan your development around the release schedule and you avoid most of the trouble.
This gets complicated quickly. If you are tired of untangling someone else’s mess and just want your site to work, get in touch with my team. We have probably seen it before.
