define( 'WP_AUTO_UPDATE_CORE', 'minor' );This line, or its absence, decides whether WordPress 7.0.1 installs itself on your sites the day it ships. Minor core updates have applied themselves in the background on stable installs for years, and since 5.6 new installs also opt into major auto-updates unless an admin turns them off. The Upgrading handbook documents this. So when the first WordPress maintenance release for the 7.0 branch lands, most of the sites I look after will already be running it before I open the announcement.
The trigger for this post is a short call on Make WordPress Core for release managers to cover the 7.0.x branch. WordPress 7.0.0 shipped May 20, 2026, and 7.0.1 is tentatively targeted for later in June. A major release squad fills a long list of named roles. The maintenance crew, per the post, is often 1 to 3 people.
Who runs a WordPress maintenance release
Those 1 to 3 people do four things, according to the call: triage bugs with committers and component maintainers, draft the release announcement, prepare and run release day activities, and update the documentation so the next team has an easier run. Members of the 7.0 cohort are invited to stay on, but you do not need to have served on a major release squad to volunteer. The comments under the post already have takers, including a core committer offering to run weekly 7.0.x bug scrubs until 7.1 ships.
Core has had consistent squad leads per branch since a trial in 2021, which the call links to, and the model stuck because a maintenance branch needs judgment more than headcount. Most of the job is deciding which fixes are safe to backport and which stay in trunk.
Who takes that job matters to you even if you never volunteer. That small team decides what reaches your sites, because a minor release is bugfix only, with regressions and security fixes at the front of the queue. The ticket you filed against 7.0 in its first week either gets triaged into the 7.0.x branch or it waits for 7.1. When a client asks why their bug survived “the update”, the honest answer is that the 7.0.x branch is deliberately conservative. I wrote about the 7.0 release process before, and about what the leaner 7.1 squad means; the 7.0.x work runs on the same schedule.
What to check before 7.0.1 lands
First, find out what your update policy is, because hosts and old wp-config.php files override the checkbox on the Updates screen. Search your config for WP_AUTO_UPDATE_CORE and AUTOMATIC_UPDATER_DISABLED before release day. If a developer who left years ago set the first one to false, that site has quietly skipped every security release since, and nobody noticed because nothing broke.
wp core check-update
wp core update --version=7.0.1 # staging copy, once it existsSecond, update a staging copy before anything production-facing moves. On WooCommerce stores I run a test checkout after the update, and on everything else I glance at the error log that evening. The breakage I expect after a minor release usually sits outside core: a mu-plugin doing a version_compare on a hard-coded branch, or a host with restrictive file permissions that turns a background update into a half-written core directory. Both are five-minute fixes if you catch them the same day and a bad week if the client catches them first.
Do not answer any of the above by setting WP_AUTO_UPDATE_CORE to false. The 7.0.x team covers maintenance and security releases, and pinning core means you have volunteered yourself for their job, on your own schedule, with none of their process. For a site you do not watch daily, ‘minor’ is the sane floor. If you want a hand auditing update settings across a set of client sites, or a staging pass before 7.0.1 lands, that is work I take on, so get in touch.
