Short answer: there is not one release note, there are four documents for four different audiences, and you are being handed the wrong one. As a site owner you need exactly two: the release announcement on WordPress.org News, and the About screen inside your own admin after updating. The Field Guide and the individual developer notes on make.wordpress.org are written for people maintaining code, and you only need them if somebody built something custom for your site. And when you do read them, read backwards: start at deprecations and compatibility breaks, not at the new features.
Version context (as of 2026-07-25): current stable is WordPress 7.0.2, released 2026-07-17. WordPress 7.1 is scheduled for 2026-08-19 and is in beta. The WordPress 7.0 Field Guide was published on make.wordpress.org on 2026-05-14, six days before 7.0 shipped, which is the normal pattern: the Field Guide appears during the release candidate phase.
The four documents, and who each one is for
| Document | Where | Written for | Should you read it? |
|---|---|---|---|
| Release announcement | WordPress.org News | Everyone | Yes. This is "the release note" in ordinary language |
| About screen | Your own admin, after updating | Site owners | Yes. Same content, plus it confirms which version you landed on |
| Version page in the documentation | WordPress.org documentation | Site owners and admins | When you need detail. Lists changes and the technical summary for that version |
| Field Guide | make.wordpress.org/core | Developers and plugin authors | Only if you have custom code. It is an index of developer notes |
| Individual dev notes | make.wordpress.org/core | The author of a specific plugin or theme | Almost never. Send the link to whoever wrote your custom code |
The reason people find release notes impenetrable is almost always that somebody linked them to the Field Guide. That document is doing its job correctly. Its job is not you.
The Field Guide is linked from the release announcement, from the About screen, and from the version's documentation page, so you will keep encountering it. Knowing that it is the developer index, and that skipping it costs you nothing, is most of the skill.
Decoding the version number first
The number tells you how much attention to pay before you read a word of the notes.
- 7.0 to 7.1 is a major release. New features, changed behavior, occasional removals. It does not install itself: it waits in Dashboard > Updates for you to click.
- 7.0.1, 7.0.2 are minor releases: bug fixes and security patches, no new features. These install automatically on most sites, because WordPress has enabled automatic background updates for minor releases since version 3.7.
- A minor release described as a security release is the one to stop and take seriously, even though you probably already have it. It means a vulnerability was disclosed and patched.
So: minors are usually already done and worth a glance. Majors are the ones you plan for. What actually happens during a WordPress update covers the mechanics of both.
Read it backwards: the four things that matter, in order
A release announcement leads with what is exciting. Your interests are almost the reverse. Read in this order.
1. Requirements changes
The single most consequential line in any release note, and it is usually one sentence near the bottom. WordPress 7.0 raised the minimum PHP version to 7.4. A requirement change can mean the update simply will not install on your server, or that your host has to move you first.
Search the page for "PHP", "minimum", "requires" and "MySQL". If any of those changed, that is your first job, before anything else in the release.
2. Removals and deprecations
The words to search for are removed, deprecated, no longer, and backward compatibility. This is the section that predicts breakage, and it is the section that features-first reading skips.
The distinction matters:
- Deprecated means it still works, but it is marked for future removal. Nothing breaks today. You have been given notice.
- Removed means it is gone in this release. Anything relying on it stops working the moment you update.
- A backward compatibility break means existing behavior changed. Nothing was removed, but something now behaves differently, and that is the hardest category to test for.
If you see "removed" next to something your site uses, you do not have a reading problem, you have a testing job. Do it on a staging copy, and see checking plugin compatibility before updating.
3. Changed defaults
Search for "by default" and "now enabled". A new feature that is off by default is an option. A changed default is a change to your site whether or not you wanted it, and those are the ones that produce "nothing I did caused this" support threads a week later.
4. Then, finally, the features
Read these last, and read them as a shopping list rather than a warning. Nothing here can break your site, and most of it you can adopt at your own pace or ignore entirely.
Translating the vocabulary
You do not need to learn to code to read these documents. You need about ten words.
| The wording | What it means for your site |
|---|---|
| Deprecated | Still works now, being phased out. Note it, do not act today |
| Removed | Gone. If something used it, that something breaks |
| Backward compatibility break | Old behavior changed. Test the feature that relied on it |
| Hook, filter, action | Attachment points plugins use. Changes here affect plugins, not you directly |
| Opt-in / behind a flag | Off unless someone turns it on. Ignore |
| Enqueue, register, API | Developer plumbing. Not your department |
| Regression | Something that used to work and stopped. Usually fixed in the next minor release |
| Bundled themes | The Twenty-something default themes. Only relevant if you use one |
| Under the hood | Performance and internals. Nothing to do |
| Field Guide | The developer index. Send it on, do not read it |
Where the actual bug list lives
Release announcements summarize. If you want to know whether a specific bug you reported got fixed, the announcement will rarely say.
The version's page in the WordPress documentation carries a fuller list of changes for that release, including the summary of what changed at the file level. Beyond that, WordPress development happens in public on the project's ticket system, where every change is recorded against a numbered ticket. You do not need to use it, but knowing it exists is the answer to "how do I find out if X was fixed": search the ticket system for the symptom.
Turning a release note into a decision
Once you have read the two documents that matter, you have four possible answers, and only four:
- Update now. Nothing removed that you use, no requirement change, and it is a security release. This is most minor releases and they have usually installed themselves already.
- Update after testing. A major release with no red flags. Stage it, click it, check your important pages.
- Update after a prerequisite. A requirement changed. Fix the requirement first, usually with your host.
- Wait for the first minor release. Legitimate for a complex site on a major version. The cost is running without the security fixes in that release, so it is a delay, not a decision.
For the release currently ahead, WordPress 7.1 and whether to update on day one applies this to a specific case, and the WordPress 7.x guide for site owners covers what the 7.x line has changed so far.
The honest limitation
A release note tells you what WordPress changed. It cannot tell you what your plugins did about it. Most post-update breakage is not core failing, it is a plugin that has not caught up, and no amount of careful reading of the core announcement will surface that. The release note is one input. The other is the pre-update checklist, which looks at your own site.
FAQ
Where do I find the official WordPress release notes?
On WordPress.org News, published the day a release ships. The same content appears on the About screen in your own admin after you update, and the version's documentation page carries a longer list of changes.
What is the WordPress Field Guide, and do I need it?
It is a post on make.wordpress.org published during the release candidate phase, collecting all the developer notes for that release. WordPress 7.0's was published on 2026-05-14. It is written for plugin and theme authors. As a site owner you need it only to forward to whoever maintains your custom code.
What is the difference between a major and a minor WordPress release?
A major release (7.0 to 7.1) adds features and can change behavior, and waits for you to click Update. A minor release (7.0.1, 7.0.2) fixes bugs and security issues and installs automatically on most sites.
What does "deprecated" mean in a WordPress release note?
The feature still works but is scheduled for removal in a future release. It is advance notice, not a break. "Removed" is the word that means something stopped working today.
Should I read release notes before or after updating?
Before, for a major release, because the requirements and removals sections are what decide whether you should update at all. After is fine for minor releases, which have usually already installed themselves.
