WordPress Versions, Updates and Release Cycles

WordPress is actively developed and receives major releases, maintenance releases and security updates.

A reliable website needs an update process that combines prompt security response with backups, testing and verification.

How WordPress Version Numbers Work

WordPress versions commonly use a number such as 7.0.2.

The numbers represent a release line and subsequent updates, but WordPress does not use semantic versioning in the same way as many software libraries.

In practical WordPress usage:

• A release such as 7.0 is a major release.
• A release such as 7.0.1 or 7.0.2 is a minor release in that branch.

Major releases can introduce features, APIs, editor changes, database changes and compatibility considerations.

Minor releases usually focus on maintenance, bug fixes and security, though you should always read the release notes.

The Current Stable Release Changes Over Time

At the time this article was reviewed on 3 August 2026, the latest stable release was WordPress 7.0.2, published on 17 July 2026 as a security release.

WordPress 7.1 was in pre-release testing and scheduled for 19 August 2026.

This information becomes outdated quickly. Check the official WordPress download page and release announcements before acting on it.

The lasting principle is to run a currently supported stable version and apply security updates promptly.

Major Releases

Major WordPress releases can include:

• New editor and design features.
• New blocks and APIs.
• Administration changes.
• Accessibility and performance improvements.
• Database upgrades.
• Developer deprecations or compatibility changes.

Major releases are developed publicly through a cycle that can include planning, development, beta versions, release candidates and the final stable release.

Complex websites should test major releases in staging before production deployment.

Minor and Security Releases

Minor releases can address:

• Regressions.
• Maintenance issues.
• Compatibility problems.
• Security vulnerabilities.

Security releases may be applied automatically and should be treated with urgency.

In July 2026, WordPress 7.0.2 addressed critical and high-severity security issues, and the project enabled forced automatic updates for affected versions. This illustrates why an update strategy must allow rapid security response.

Beta Versions

Beta releases are pre-release software intended for testing and feedback.

They should not be installed on production or mission-critical websites.

Beta testing helps identify issues before the stable release and allows theme and plugin developers to prepare compatibility updates.

Use an isolated development or staging environment with a recoverable copy of relevant data.

Release Candidates

A release candidate, or RC, is a later pre-release stage considered close to final.

It still requires testing and is not intended for normal production use.

Several release candidates may be published when additional issues are discovered.

Nightly and Development Builds

Development builds contain work that may be incomplete or unstable.

They are useful for contributors and specialized testing, not for ordinary websites.

How WordPress Core Updates Work

WordPress can update through the administration interface, command-line tools, hosting systems or deployment automation.

The built-in process can:

• Download the update package.
• Place the website in maintenance mode where needed.
• Replace core files.
• Run database upgrades if required.
• Update translations.

Do not interrupt an update process unnecessarily.

If an update fails, follow documented recovery steps rather than repeatedly refreshing or deleting files without a backup.

Automatic Updates

WordPress supports automatic background updates for core, and administrators can configure automatic updates for themes and plugins.

Hosting providers may add their own systems.

Automatic updates can reduce exposure to known vulnerabilities, especially for small maintenance and security releases.

They can also introduce compatibility risk when a website has fragile or untested dependencies.

Choose a policy based on:

• Website criticality.
• Plugin and theme quality.
• Staging availability.
• Monitoring.
• Backup reliability.
• Ability to roll back.
• Speed of manual response.

A policy that disables all automatic updates without providing rapid manual maintenance is not a security strategy.

Theme and Plugin Updates

WordPress core is only part of the update surface.

Themes and plugins can contain vulnerabilities, compatibility changes and database migrations.

Before a significant update:

• Read the changelog.
• Confirm WordPress and PHP compatibility.
• Review support reports when appropriate.
• Test critical workflows.
• Create a backup.
• Confirm license and update access.

Remove abandoned or unnecessary software instead of leaving it permanently outdated.

A Safe Update Workflow

For an important website:

1. Review available updates and release notes.
2. Identify security urgency.
3. Confirm recent backups.
4. Copy the current site to staging where appropriate.
5. Apply updates in staging.
6. Test critical pages and workflows.
7. Review logs and Site Health.
8. Schedule production deployment.
9. Apply the update.
10. Clear relevant caches.
11. Verify the frontend and administration area.
12. Monitor errors, transactions and integrations.

For emergency security releases, shorten the process without removing backup and verification.

Compatibility Does Not Mean “No Visible Error”

A website can load while still having update-related problems.

Test:

• Editing and publishing.
• Forms.
• Login and account actions.
• Search.
• Ecommerce checkout.
• Scheduled tasks.
• API integrations.
• Responsive layouts.
• Caching.
• Error logs.

Database Upgrades

Some WordPress, theme or plugin updates modify the database.

A file rollback may not reverse database changes safely.

This is why backups should capture both files and database and why rollback instructions should be product-specific.

Supported Versions

The WordPress project can backport selected security fixes to older branches as a courtesy, but official release documentation states that only the latest version is actively supported.

Do not rely on long-term operation of an outdated branch as the normal maintenance plan.

PHP, database and browser support also evolve. Keeping WordPress current while the server remains obsolete does not create a healthy platform.

Release Notes and Field Guides

Before major updates, review:

• Official release announcement.
• Version documentation.
• Developer Field Guide when relevant.
• Theme and plugin compatibility information.
• Hosting notices.

These sources explain changes that a generic “update available” notification cannot summarize fully.

Update Ownership

Every website should have a named owner for:

• Reviewing updates.
• Creating and verifying backups.
• Testing.
• Approving deployment.
• Responding to failures.
• Monitoring security announcements.
• Maintaining licenses and vendor access.

Without ownership, updates are often delayed until a problem becomes urgent.

Frequently Asked Questions

Should I update WordPress immediately?

Security releases should be applied promptly. Major releases may be tested in staging first, but delays should be deliberate and time-limited.

Can an update break a website?

Yes. Compatibility problems, custom code, server versions and database changes can cause issues. Backups, staging and testing reduce risk.

Should I use beta versions to get features early?

Not on production. Beta and release candidate versions are for testing and contribution.

Can I downgrade WordPress after an update?

It may be possible, but database changes and security concerns make arbitrary downgrades risky. Restore a verified backup or follow an appropriate recovery plan.

Section Complete

You have completed WordPress Fundamentals.

Continue to Content Architecture to learn how WordPress organizes posts, pages, custom post types, taxonomies, fields, archives and structured content models.