Versions and Release Cycle

WordPress does not use semantic versioning. The Core Handbook defines a major version by the first two numbers (6.8, 6.9, 7.0, 7.1) and a minor version by the third (7.1.1, 7.1.2, 7.1.3):

The step from 6.9 to 7.0 is exactly as big as the step from 6.8 to 6.9: the first digit rolls over after .9 and carries no extra meaning. A "7.0" is not a rewrite and does not break more than any other major release. Older books read the numbers the semantic-versioning way. Pro WordPress in particular treats X as the major version, Y as a minor feature release and Z as a patch, which leads to the wrong conclusion that 6.9 → 7.0 is the only "big" upgrade and that 6.8 → 6.9 is a small one. In WordPress, every X.Y change is a major upgrade that deserves a staging test, and every Z change is a maintenance or security release that should be applied quickly.

The cadence has changed several times, so statements such as "WordPress ships three major releases a year" are only approximately true:

The roadmap states that new features are frozen one month before a release, and that projected dates are for rough planning only. Plans for later years are announced on Make WordPress; check the roadmap rather than assuming a fixed rhythm.

Most user-facing features (blocks, the Site Editor, Global Styles, the admin screens built with DataViews, the Interactivity API) are developed in the Gutenberg plugin and merged into core during each alpha phase. The plugin ships a release candidate and then a stable version on a two-week cycle (24.1.0 on 2026-09-30, 24.2.0 on 2026-10-14, 24.3.0 RC1 on 2026-10-20). Version 24.2.0 requires WordPress 7.0 or later and PHP 7.4 or later.

The Block Editor Handbook keeps the mapping of Gutenberg versions to core releases:

This mapping explains two common surprises. A feature described in a Gutenberg release post (for example a block support added in 24.x) is not in core until the next major release that includes that Gutenberg version. And a feature can appear in Gutenberg as an "experiment" for many releases before it ships, or never ship at all; React 19, for example, was deferred beyond 7.1 and continues as an experiment in the plugin. Installing the Gutenberg plugin on a production site gives early access to features, but it is aimed at early adopters and testers: it changes the editor every two weeks, and its experiments are opt-in for a reason. Lumen Press installs it only on staging.

There are four supported ways to run a beta, a release candidate or a nightly build. None of them belongs on a production site.

The Lumen Press staging server is moved through the 7.2 cycle with WP-CLI. Every command below was run against a WordPress 7.1.3 site in a container; take a database backup first, because there is no supported way back (see the end of this section):

Source: WP-CLI Commands: wp core update and Core Handbook: Beta Testing

Developers who test a plugin against the next release usually prefer a throwaway environment. @wordpress/env accepts a core value that is a release ZIP URL or a WordPress/WordPress Git reference, so the lumen-catalog repository keeps one configuration for the current release and one for the beta:

Source: Block Editor Handbook: @wordpress/env

The beta configuration is a second file, .wp-env.beta.json, selected with --config:

Source: Block Editor Handbook: @wordpress/env

Source: Block Editor Handbook: @wordpress/env

Going back from a pre-release to a stable version is not supported. wp core update --version=7.1.3 --force replaces the files, and wp core update-db then only rewrites the stored db_version option (from 64486 back to 61833 in the run above); schema and data changes made by the newer version are not reverted. Restore the database backup instead. The same applies to the "Re-install" button on Dashboard > Updates.

Only the latest major branch is actively supported. As a courtesy, the security team also backports security fixes to older branches, so that sites that cannot upgrade still receive them through automatic minor updates. The 7.1.3 and 7.1.4 announcements say the fixes went to all branches still eligible, currently through 4.7 (for 7.1.4 the backports were still being published as they became ready). The eligible range shrinks over time:

A backport is not a support promise: there is no guaranteed time frame, and a fix that is too large to backport safely stays in the current branch only. The WordPress Versions page lists the backports with the same date (for example 7.0.7, 6.9.10, 6.8.11, 6.7.10, 6.6.10 and 6.5.13 on 2026-10-06, next to 7.1.3).

Minor releases, including these backports, are installed automatically by default. Sites installed on 5.6 or later also receive major releases automatically, unless a version-control checkout is detected. The WP_AUTO_UPDATE_CORE constant selects the policy; Lumen Press production keeps automatic minor updates and takes major releases through staging:

Source: Advanced Administration Handbook: Configuring Automatic Background Updates

true enables development, minor and major updates, false disables all three, and 'minor' enables only minor updates. A site that runs a development version (a beta, RC or nightly) receives development updates, which is how the staging site moves from Beta 2 to Beta 3 by itself. Turning automatic updates off completely (AUTOMATIC_UPDATER_DISABLED) also stops security releases and is discouraged. The full set of constants and filters, rollback of failed plugin updates and update strategies for teams are covered in Updates and Auto-Updates.

None of the older books covers the releases after 6.6. The table lists the changes that later pages of this sub-section rely on; the field guide of each release has the full list.

The Core Handbook keeps a table of the PHP versions each WordPress release supports. It marks each pair as supported or not:

"Supported" means core runs on that PHP version; it does not mean every plugin does. The requirements page recommends PHP 8.3 or later, and the Hosting Handbook recommends 8.4 or later; PHP 7.4 has had no security support from the PHP project since November 2022. The practical rule for Lumen Press is the newest PHP version that both the current WordPress branch and every active plugin support. The PHP-side changes between versions are covered in PHP: What’s New and Migration, and server requirements in Requirements and Hosting.

A plugin or theme declares the versions it supports in its main file header (a theme in style.css):

Inside the code, there are two kinds of checks. is_wp_version_compatible() (5.2+) compares against a release number; it strips -beta, -RC and other suffixes, so on 7.2-beta2 a check for 7.2 already returns true. function_exists() or class_exists() checks for an API directly, which also works when the API comes from a feature plugin and is the better choice when a function exists. The lumen-catalog plugin uses both, in its main file:

Source: Plugin Handbook: Header Requirements and Code Reference: is_wp_version_compatible()

Source: Code Reference: wp_get_wp_version()

On 7.1.3 every check is true, and wp_get_wp_version() returns the real version even if another plugin has changed the global. On a site still running 6.8, the header alone stops the plugin:

Source: WP-CLI Commands: wp plugin activate

Raising Requires at least is a decision with consequences: sites below it stop receiving the plugin’s updates from the directory, including its security fixes. Lumen Press raises it only when the plugin needs an API from a newer release, and keeps it at most two major releases behind the current one. The plugin header and lifecycle are covered in detail in Plugin Fundamentals.

All corrections are collected in Where Older Books and Tutorials Are Outdated.