A long-term client called me late on the 10th. “Ahmad,” he says, “I see WordPress 6.9 is finally out. My dashboard is begging me to update. Should I just hit the button?” My answer is the same every time: not before I have read the dev chat notes. On a production site I want to know what changed before anything gets applied.
The WordPress 6.9 release management notes from the December 10, 2025 dev chat read better than most. Usually a major version lands and the core team is already chasing some “showstopper” that slipped through, but the feedback this time has been quiet enough that they decided against an immediate 6.9.1 maintenance release. Stability is a fair read of that. Updating blind is still a bad idea.
What the dev chat tells you about updating
On a high-traffic WooCommerce store or a large corporate site, core updates are not something you guess at. The summary on the official Make WordPress Core blog puts planning for 6.9.1 into the new year, which reads as confidence in the 6.9 “Gene” release.
I learned this the hard way on a project a few years back. I updated a client’s site to a .0 release the hour it launched, figuring that months of beta had shaken out anything serious. Ten minutes later their custom product configurator was returning 500 errors, thanks to a small change in how the REST API handled certain schema validations. I spent the rest of that night rolling back and writing a polyfill. These days I wait for the dev chat to confirm there are no “immediate response” issues before I touch production.
Gutenberg 22.2 and the workflow problem
The dev chat also raised something familiar to anyone doing custom block development: the labels in the Gutenberg repository are not clear. You find a bug, you find the issue for it, and you still cannot tell whether it is ready for a patch or whether the implementation is still being argued over. If your block editor is behaving oddly after the Gutenberg 22.2 update, keep in mind that the “Needs Patch” labels are in a messy state right now. Hacking core blocks before you know where an issue stands is how you end up maintaining a fork of it.
/**
* A safe way to handle major core updates for enterprise clients.
* This allows minor security patches but forces a manual review for major releases.
*/
add_filter( 'allow_major_auto_core_updates', 'bbioon_manage_major_releases', 10, 1 );
function bbioon_manage_major_releases( $allow ) {
// For production environments, we want to vet major updates like 6.9 first.
if ( defined( 'WP_ENVIRONMENT_TYPE' ) && 'production' === WP_ENVIRONMENT_TYPE ) {
return false;
}
return $allow;
}What to do about it
6.9 looks solid, which is not the same thing as a reason to skip your own process. This is the order I am working through for client sites this week:
- Wait for the dust to settle, because with 6.9.1 held back until next year there is a stable window to test in staging.
- Watch the Gutenberg repo if you lean heavily on the block editor, since those workflow discussions are still open.
- Test your custom hooks, particularly anything touching the REST API or block rendering.
Major version transitions get complicated fast, especially on a site carrying years of custom code. If you would rather not spend the week debugging it, drop my team a line. We have probably seen it before.
Are you hitting the update button today, or are you waiting for the new year?
