WordPress 6.9 Release Candidate: What You Need To Know

Just last week, a client hit us up in a panic. Their big e-commerce launch was stalled. A critical hotfix for a payment gateway integration wasn’t deploying, and the release manager was tearing his hair out. We dug in, and here’s the kicker: they’d pushed the fix during what they thought was a standard maintenance window, but it coincided with the WordPress 6.9 Release Candidate phase. Total nightmare, right?

This isn’t some obscure edge case, man. When WordPress hits Release Candidate (RC), the rules of the game change entirely. You can’t just commit code willy-nilly anymore. Ignoring these specific WordPress Release Candidate Policies is how you end up with rejected patches, missed deadlines, and a very unhappy client. Let me walk you through what RC really means and how to navigate it without losing your sanity.

Understanding the WordPress Release Candidate Policies

The core team at WordPress is focused on stability and final polish once a version enters RC. This isn’t the time for new features or major refactors. The shift is dramatic, and it’s all about locking things down to ensure a smooth public release. The communication from the core team, like this one over at make.wordpress.org/core, is always crystal clear, but sometimes it gets lost in the shuffle of daily development.

The String Freeze: Don’t Break Translations

One of the first things that happens is the “String Freeze.” This is critical for the Polyglots team. They work tirelessly to translate WordPress into hundreds of languages. Add a new string during RC, and you effectively halt their progress, potentially delaying translations for the entire release. My client’s initial bug fix, a small text change in an error message, actually introduced a new string. I thought, “It’s just one line, what’s the big deal?” But it was a huge deal. It meant a hold-up.

The rule is simple: no new strings. Existing strings can be removed or duplicated, sure, but nothing new. If you find a buggy string that can’t be translated properly, you need to engage with the Polyglots team leadership. Don’t just “fix” it on your own. You’ll thank me later.

<?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 types of tickets make it onto the milestone:

• Regressions: These are bugs introduced during the current 6.9 development cycle. Critical stuff.
• Test suite expansion: Tests can always be committed. This is about improving stability, not changing functionality.

If your “urgent fix” isn’t a regression, it’s likely not going in. Period. My client’s payment gateway issue, thankfully, was a regression introduced in the beta phase, so it qualified. But anything else, a new enhancement, a refactor, it waits for WordPress 7.0-alpha, which, by the way, the trunk is already open for.

Backporting Commits: The Double Sign-Off

Even for eligible fixes, getting code into the RC branch (the 6.9 branch, in this case) isn’t a simple commit. Any production code requires a double sign-off from two core committers. You use the dev-feedback keyword to get that second review, and dev-reviewed once it’s approved. This isn’t just bureaucracy; it’s a safety net. It means more eyes on critical changes, preventing new issues from creeping in right before release. We almost missed this step, thinking our patch was straightforward enough, but that double-check saved us from a potential headache.

<?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"
?>

So, What’s the Real Takeaway Here?

Look, the WordPress Release Candidate phase is a crucial period, and it demands a different mindset from developers. It’s not business as usual. Understand the string freeze, know what kind of tickets are accepted, and respect the double sign-off process for backports. These policies are there for a reason: to ensure the stability and quality of WordPress for millions of users. Trying to shortcut them will only lead to more work for you, and more headaches for everyone else. Plan your development cycles accordingly, and you’ll save yourself a world of pain.

Look, this stuff gets complicated fast. If you’re tired of debugging someone else’s mess and just want your site to work, drop my team a line. We’ve probably seen it before.