Last month a long-term client of mine, running a high-volume WooCommerce store, asked whether WordPress was “slowing down”. They had seen only two major updates land in 2025 and read it as the platform losing steam. 2025 was a quieter year, with 6.8 and 6.9 and nothing else, but the WordPress release schedule for 2026 goes back to three major releases a year.
The proposal discussed at make.wordpress.org lays out a return to the four-month cycle, in line with the “release early, release often” philosophy. For a developer that means fewer big bang breakages and more small shifts you can absorb one at a time. For a site owner it means the maintenance schedule just got 50% busier.
The risk of the two-release mindset
I got caught by this myself in 2025. With the major releases spread further apart, I assumed there was time to refactor some legacy hooks in a custom shipping module. By the time 6.9 “Gene” arrived in December, a run of minor deprecation notices had been piling up in the background where I was not looking. I spent a weekend reading logs I should have been checking months earlier.
Three releases in 2026 leaves no room for that. Check compatibility on a four-month rhythm and core, plugins and custom code stay roughly in step with each other. Skip a couple of cycles and the gap between them is what you end up paying for.
Logging deprecations before the next release
You want to know what breaks before anyone clicks Update. Plain WP_DEBUG is noisy and it eats disk space. Something narrower works better: send deprecation warnings to their own file, so the next stop on the WordPress release schedule tells you what to fix instead of surprising you.
/**
* Custom logger to catch deprecation notices before major releases.
* This keeps your main error log clean for actual runtime crashes.
*/
add_action('deprecated_function_run', 'bbioon_log_deprecations', 10, 3);
add_action('deprecated_argument_run', 'bbioon_log_deprecations', 10, 3);
add_action('deprecated_hook_run', 'bbioon_log_deprecations', 10, 3);
function bbioon_log_deprecations($item, $replacement, $version) {
$log_file = WP_CONTENT_DIR . '/bbioon-deprecations.log';
$message = sprintf(
"[%s] Deprecated: %s in version %s. Use %s instead." . PHP_EOL,
date('Y-m-d H:i:s'),
$item,
$version,
$replacement ? $replacement : 'no replacement'
);
error_log($message, 3, $log_file);
}Drop that into staging now, and by April, when the first 2026 release lands, you have a list of what needs fixing rather than a weekend of guesswork.
Getting ready for a busy 2026
Three releases a year is good news on balance. It keeps the platform current and stops a year of heavy changes from arriving in a single update. It does ask more of whoever maintains the site, though: someone reading the Core team’s roadmap, not just clearing red notification circles.
This gets complicated quickly once there is custom code in the mix. If you would rather not spend the 2026 cycle debugging it, drop my team a line. We have probably seen it before.
Is your maintenance plan ready for a release every four months, or are you still catching up on 2025?
