If you hit a bug in a block editor package and want to know which version of @wordpress/components shipped with WordPress 7.0, the old move was to open the WordPress version changelog and scan the package list under that release. As of 7.0 that list is gone. The changelog now carries a note instead, and the note only appears where information is available.
The Documentation team announced this together with a revamp of the versions page in a post on Make WordPress. The post covers three things: the versions page split, the changelog change, and a deduplication pass over the block docs. I’ll take them in the order that matters to me, which is backwards. Most of it is housekeeping, and good housekeeping at that, but the package list was the one part I used, so I went looking for where that information lives now. It still exists, it just isn’t on wordpress.org anymore.
Where the package versions live now
Two places, and both are more current than the changelog ever was. The first is npm. The block editor packages are published with a dist-tag per WordPress release, wp-7.0 for 7.0, which the Block Editor Handbook documents as part of the release process. npm view prints every tag at once, and installing with the tag gets you exactly what core bundled:
# what core bundled for each release
npm view @wordpress/components dist-tags --json
# install exactly the version in WordPress 7.0
npm install @wordpress/components@wp-7.0
# what a specific site is actually running
wp eval 'global $wp_scripts; echo $wp_scripts->registered["wp-blocks"]->ver;'The second is the site itself. Core registers each package as a script handle, and the handle’s version string is the package version, so when you want to know what a specific install is running, WP-CLI answers faster than any doc page. I use this most on stores where several plugins bundle their own copies of these packages, because the core version tells you what the editor falls back to. It doesn’t tell you which copy a given plugin loads.
This lookup matters because the @wordpress packages move on their own schedule, and a WordPress release snapshots whatever was ready that week. When the editor misbehaves right after a core update, the first useful fact is whether a package jumped a major version, because that tells you whether to go read that package’s changelog or suspect your own code. The old changelog page answered it in one scroll. npm answers it in one command, you just have to know the command.
One hedge before you build on this. The handbook says the wp/X.Y tags are cut from the release branches for each WordPress release, so major versions are safe. I have not verified that every point release gets its own tag, so check that the tag exists before you script anything against 7.0.1. The wordpress-develop repo on GitHub has the same answer in package.json on the release tag if npm ever disagrees with you.
Why the versions page got split
The source post says the single WordPress Versions page was split “due to the size of the file”, which is the least glamorous reason available and the most believable one. The main page now starts at 5.0 and will keep taking future releases. Everything from 0.7 to 4.9 moved to a separate page, WordPress Versions 0.7 to 4.9, kept for historical reference. The order also flipped from oldest-first to newest-first, which matches how nearly everyone reads a version list anyway. For most people this is a strict improvement.
Each version still links to its own release notes, which remains the fastest way to answer when a feature appeared or which release changed a behavior. The split only moves where the list of versions lives. The historical page is frozen by design, so only the page that takes new releases keeps growing.
One rough edge came up in the comments on the announcement. If you scroll the main page backwards in time, you reach 5.0 and stop, because the link to the older page sits at the top where you started. Ben Keith flagged it, and Estela from the docs team agreed a link at the bottom is doable, so I expect that gets fixed. Until it does, anyone researching 4.x behavior needs the second page directly, and internal wiki links that assumed a single page are worth updating now rather than after someone gets stuck.
What the changelog change means for your site
Core didn’t change, so there’s nothing to update and nothing that breaks. The changelog edit is documentation only. What changes is your references. If your agency handbook, a plugin readme, or a client handover doc sends people to the changelog for package versions, those links still load, but from 7.0 onward the table they were sent for won’t be there.
the list of @wordpress packages is no longer specifically updated for each release. Instead, each release will include a note with more information where available.
Read that literally: some releases will explain a big package jump, others will say nothing, and you can’t tell from the changelog which case you’re in. I’ve written before about how vague changelogs cost you in support time, and this is the same problem with the author swapped. The risk is missing information in a page that still looks authoritative.
These references also get copied around without anyone noticing. A support doc that links the changelog ends up pasted into tickets and Slack answers, and none of those copies know the page changed underneath them. So the practical step is a small one: for anything that depends on exact package versions, make npm or wordpress-develop the source of truth in your own docs, and treat the changelog as prose.
What changed in the block docs
The Advanced Settings sections on individual block pages no longer repeat the same general settings on every block. They link to one shared advanced settings page, and block-specific settings stay on the block’s own page. The work is tracked in issue #2287 on the Documentation-Issue-Tracker. If you write docs for your own plugins, this is the most interesting part of the announcement. Duplicated settings text drifts the moment one block diverges, and a shared page plus per-block exceptions stays accurate longer, at the cost of one extra hop for the reader. I’d make the same trade for plugin documentation, and I’ve been consolidating repeated setup steps out of my own readmes for the same reason.
The question I’m still sitting on is whether those per-release notes will get written. A note that appears only when someone remembers it is the first thing to skip in a release crunch, and the changelog is where a support person looks first when a client says blocks broke after an update. If the notes go stale, package history becomes something only developers who know about dist-tags can find. That’s why I’d watch the next two releases before deciding how much to lean on the changelog. And if you maintain client sites and want their internal docs pointing at sources that won’t change shape like this, that’s a cleanup I’m glad to help with.
