The WordPress Release Cycle Explained for Site Owners

A pending core update is either a small fix you should let through today or a feature release that deserves a test first, and the version number tells you which. The WordPress release cycle is more regular than it looks from the dashboard: a few feature releases a year, each with a public schedule, followed by smaller releases that carry bug and security fixes.

Once you can read that pattern, updates become calendar entries and stop being reactions to a red badge in the admin.

Reading a WordPress version number

The first two numbers together name a major release. 6.9, 7.0 and 7.1 are three major releases of equal standing. The third number is a minor release: 7.1.2 is the second round of fixes for 7.1. That is the whole scheme, and it differs from the semantic versioning most software follows in two ways that catch people out.

First, a version ending in .0 is no bigger than its neighbors. The counter simply rolls over after .9, so there is no "WordPress 7" generation in the sense of a rewrite. Do not budget extra risk for a .0 release or assume that a .1 is a light one. Read what each release contains.

Second, any major release may change something a plugin relied on or raise the server requirements. Version 7.0, for example, raised the minimum PHP version to 7.4. The number gives no warning of this. The release notes do.

Each major release also carries the name of a jazz musician. It is a tradition and has no technical meaning.

The stages of a WordPress release cycle

The release cycle described in the core handbook runs for roughly four months and is led by a release squad drawn from the project's contributor teams. It passes through fixed stages:

• Planning and development. Features are proposed, built and merged. Builds from this stage are called alpha and nothing in them is settled.
• Beta. From Beta 1 onward no new features or enhancements are accepted. The work is finding and fixing bugs, with a new beta roughly every week.
• Release candidate. RC1 means the team considers the release ready unless testing proves otherwise. Text strings are frozen so translators can finish, and only regressions introduced during this cycle are fixed.
• Launch. The final version appears under Dashboard > Updates.

You can ignore the alpha stage completely. The date that matters to a site owner is RC1, for two reasons. Around that day the project publishes the Field Guide, a single page that links every developer note for the release: what changed, what was deprecated, what plugin and theme authors need to test. And from that day the code is close enough to final that a staging copy running the release candidate will show you what breaks on your site, with two or three weeks in hand to fix it.

The WordPress Beta Tester plugin switches a site to beta or release candidate builds. Use it on staging or a local copy only. A pre-release build has no place on a live site, however stable it feels.

Minor releases carry the fixes

Once a major version is on millions of sites, real use finds bugs that testing did not. Minor releases deliver the repairs. A maintenance release fixes bugs, a security release closes vulnerabilities, and many releases do both at once.

The rule the core team works to is that a minor release should not add features or new files. That restraint is why minor releases install themselves by default on every WordPress site, and why they are safe to apply without a staging pass.

Security releases follow their own etiquette. Details of the vulnerabilities are published together with the fix, not before, and the announcement asks site owners to update immediately. Take that literally. From the moment of release, the fix is public, and so is a strong hint about where the weakness was. A minor release that has not installed itself within a day or two is worth investigating. The usual causes are auto-updates switched off by a constant, a scheduler that is not running, or file permissions. Our guide to WordPress auto-update settings explains how to check each one.

Which versions still receive fixes

Officially, one: the latest major release. WordPress has no long-term support version.

In practice the security team has for years backported security fixes to older branches, currently as far back as 4.7. The project describes this as a courtesy that happens when it is possible, and ordinary bug fixes are not backported at all. So an old branch can still receive a security release now and then, and that is the most it will ever get.

Two other clocks run out sooner than the backports do:

• Your plugins. Plugin authors raise the minimum WordPress version they support over time. Once a plugin's "Requires at least" value passes your version, you can no longer install its updates, security fixes included.
• Your PHP version. Each major release supports a stated range of PHP versions. A server on a PHP version below the minimum is not offered the new major release and stays on its old branch until PHP is upgraded.

Being one major release behind for a few weeks while you test is normal. Being years behind means living on courtesy patches, with plugins that can no longer update.

How quickly to apply each kind of release

Minor releases: the same day. Let automatic updates do it and read the email WordPress sends afterwards.

Major releases: within two to four weeks, after a test on staging. You will often hear the advice to wait for the first minor release. There is some sense in it, because that release usually follows within weeks and repairs the regressions early adopters ran into. But waiting is not testing. The first minor release fixes bugs other people reported. It does nothing for a conflict between the new version and your own custom code. If the site has a staging copy, test the release candidate or the .0 there, and update the live site when your tests pass and the plugins you depend on have declared compatibility.

Several major releases at once: avoid getting there. WordPress can jump across versions, since its database upgrade routines run in sequence, but every release you skip adds changes to untangle when something fails. The order of work for any core update is in our checklist for updating WordPress safely.

Where to follow WordPress releases

• The Releases category on the WordPress.org news blog announces every beta, release candidate, final release and minor release. If you subscribe to one thing, make it this.
• Make WordPress Core publishes the schedule page for each release, the developer notes and the Field Guide.
• The WordPress roadmap shows the planned date of the next major version.
• Inside your own site, Dashboard > Updates shows what is available, and WordPress emails the administration address after an automatic core update.
• On the command line, wp core check-update lists available versions, which is handy when you look after several sites.

Turning the schedule into a routine

For each major release, three calendar entries are enough. On the RC1 date, install the release candidate on staging and click through the site. In release week, read the announcement and check that your important plugins have shipped compatible versions. Two weeks later, update the live site.

A site built from a maintained theme and well-known plugins can follow that routine without a developer. It changes when the site runs custom code. Somebody then has to read the Field Guide with your plugin or theme in mind, test against the release candidate and fix what the new version deprecates, before your visitors find it. That reading and testing is part of what a WordPress maintenance plan covers, and the fixes themselves are routine work for the people who do custom plugin development or theme development.

Frequently asked questions

How often does WordPress release a major version?

A few times a year. One cycle takes roughly four months, and the number of releases planned per year has changed over time, so check the roadmap on WordPress.org for the next planned date instead of relying on a fixed rhythm.

Is WordPress 7.0 a bigger update than 6.9 or 7.1?

No. WordPress numbers its major releases 6.8, 6.9, 7.0, 7.1 and so on, and the change of the first digit only means the counter rolled over. Judge each release by its notes, not by its number.

Should I install a beta or release candidate on my live site?

No. Pre-release builds are for testing on staging or local copies. A release candidate is the right build for checking custom plugins and themes ahead of launch, but the live site should wait for the final version.

Is there a long-term support version of WordPress?

No. Only the latest major release is officially supported. Older branches may receive backported security fixes as a courtesy, but they get no bug fixes and plugins gradually stop supporting them.