The dates are public. WordPress 7.2 Beta 1 arrives between 20 and 22 October 2026, and the release follows between 8 and 10 December.
The release date gets the attention. The beta is the one that should change what you do, because it is the first point at which the feature set is settled enough that testing against it tells you something that will still be true in December. A bug you report in late October has a real chance of being fixed before release. A bug you find in December is a bug your users found first.
What is already queued
Two deprecations announced over the summer point straight at block developers. Inner block templates move from InnerBlocks props into block registration, with the prop-based approach deprecated. Roughly twenty core blocks have already moved.
If you ship blocks with inner templates, that migration is the highest-value thing to do before the beta rather than during it. It is mechanical work now and urgent work later.
A December release is awkward for shops
Worth saying plainly: do not update a store carrying peak trading traffic in the same week a major version ships. There is no prize for being early. The 7.2.1 that follows a few weeks later will have absorbed whatever only shows up at scale, and that is the version your client actually wants.
For everything else the sensible rhythm is to test through October and November, update the low-stakes sites the week after release, and move the rest once the first maintenance release is out. That is not timidity. Your client gets nothing from being the person who discovered the edge case.
If you have no testing routine at all
Start with one thing: get a staging copy of your most complicated client site onto the beta within a week of it landing, and use it normally for an afternoon. Not a test plan, not a checklist. Just use it. The majority of what you will find surfaces in the first twenty minutes of somebody trying to do ordinary work.
