WordPress Core Updates: Major vs Minor Versions Explained

When WordPress shows you a pending update, that version number is telling you something specific. It tells you how urgent the update is, how much risk it carries, and how carefully you should handle it.

Most site owners treat every WordPress core update the same way. They either update everything immediately and hope for the best, or they avoid all updates because they had a bad experience once. Both approaches cause problems.

The reality is that WordPress uses a version-numbering system that provides a clear framework for making the right call. Once you understand what each number means, you can handle any WordPress version update with confidence instead of guessing.

How WordPress Version Numbers Work: Major vs Minor Updates

WordPress uses a three-part version number, like 6.9.1. Each segment means something different, and the segment that changes tells you exactly what kind of update you're looking at.

Here is the breakdown:

• 6.9 is a major release. It introduces new features, editor changes, and API updates.
• 6.9.1 is a minor release. It patches security vulnerabilities and fixes bugs from the major release.

That is the entire framework. Two numbers mean new features and more risk. Three numbers mean security patches and minimal risk.

The 7.0 Question

This is where WordPress confuses people. In most software, jumping from version 6 to version 7 signals a massive overhaul with breaking changes. WordPress does not work that way.

WordPress does not follow semantic versioning. The jump from 6.9 to 7.0 follows the same rules as the jump from 6.8 to 6.9. WordPress simply counts upward: 6.7, 6.8, 6.9, 7.0, 7.1. The first digit changing carries no special significance.

WordPress 7.0 is scheduled for April 2026. It will be a standard major release, not a generational overhaul. Treat it the same way you would treat any major release.

What Changes in a WordPress Core Update

Understanding what actually changes in each type of update helps you gauge the risk. This table breaks down how to think about each version type.

Security and Maintenance Releases (The Third Number)

When WordPress goes from 6.9 to 6.9.1, or from 6.9.1 to 6.9.2, that is a security or maintenance release. These updates patch discovered vulnerabilities and fix bugs. They do not add features, change how the editor works, or modify the way plugins interact with WordPress.

These are the safest WordPress core updates you will encounter. In our experience managing roughly 200 WordPress sites, security releases rarely cause compatibility issues. They change very little code, and they are designed to be applied without disruption.

They are also the most urgent. When WordPress releases a security patch, the vulnerability it fixes is now public knowledge. In 2025, the median time from vulnerability disclosure to active exploitation was five hours. That is not a typo.

Security patches should be applied the same day they are released. WordPress has auto-applied these updates by default since version 3.7, and for good reason.

Major Releases (The First Two Numbers)

When WordPress goes from 6.8 to 6.9, or from 6.9 to 7.0, that is a major release. These happen roughly three times per year and include new features, editor improvements, and API changes.

A WordPress major update goes smoothly most of the time, but the risk is higher than a security patch. Major releases change more code, and that code interacts with your plugins and theme in ways that security patches do not.

The biggest source of risk in modern major releases is the block editor. WordPress merges months of Gutenberg plugin changes into each major release, which means plugins that extend or modify the editor can suddenly find themselves incompatible. Page builders, custom block plugins, and anything that hooks into the editor internals are the most likely to be affected.

We have seen this play out with real compatibility issues:

• Elementor 3.15 had layout rendering problems after WordPress 6.3.
• WooCommerce had checkout and stock syncing issues during the 6.2 to 6.3 transition.
• A Gutenberg update once shipped with every block missing from the editor entirely.

These are not hypothetical scenarios.

Which Plugins Are Most Likely to Break

Not all plugins carry the same risk after a core update. The more deeply a plugin integrates with WordPress core, the more likely a major release will cause a conflict.

High-risk plugins are the ones that heavily affect the front end of your site or alter the database: page builders like Elementor and Divi, e-commerce plugins like WooCommerce, and membership plugins like MemberPress or WP Membership Pro.

• A bug in a page builder could produce the white screen of death.
• A bug in e-commerce could halt all sales.
• A bug in a membership plugin could lock members out entirely.

Medium-risk plugins include established form tools like Gravity Forms and Contact Form 7. These have been around for a long time, are well tested, and rarely cause problems after a core update.

Low-risk plugins are simple, focused tools like Classic Editor or Akismet. We have never experienced a core compatibility issue with these.

The simple framework: if a plugin heavily determines the user experience or the user interface, be more cautious after a core update. For high-risk plugins, we recommend waiting 24 to 48 hours after a major core release before updating them, unless you can clearly see that the update is a security patch.

The Gutenberg Factor

This deserves its own mention because it is the single biggest compatibility concern in modern WordPress updates, and most guides do not address it.

The Gutenberg plugin releases updates every two weeks. WordPress core incorporates six or more months' worth of those changes into each major release. That is a lot of change hitting production sites at once.

If your site uses a page builder, custom blocks, or plugins that modify the editing experience, major releases warrant extra attention. This is where testing on a staging environment before updating production becomes genuinely important, not just a nice-to-have.

Should I Update WordPress Core? How to Handle Each Version

Here is the decision framework we use across our fleet of managed sites.

Security Releases: Update Immediately

These should be applied the same day. The risk of not updating is almost always greater than the risk of updating. If your site has auto-updates enabled for minor releases, this happens automatically, which is the approach we recommend for most sites.

Major Releases: Update Carefully

Run a major core update on its own. Do not mix it with an Update All.

This is one of the most important pieces of advice we give clients. If something goes wrong after a major core update, you need to know the core update was the cause. If you updated the core, twelve plugins, and a theme at the same time, you have no way to isolate the issue.

For organizations without professional management, here is the approach we recommend (covered in detail in our safe WordPress update guide):

1. Take a full backup before doing anything. Verify you can restore from it.
2. Update core first, by itself. Check your site afterward. Load the homepage, test your forms, and verify your checkout or login flow works.
3. Then update plugins, ideally one at a time or in small batches.
4. Update your theme last.

Before running any major core update, use this checklist:

For major releases specifically, there is no harm in waiting a week or two after the release date. This gives plugin and theme developers time to release their own compatibility updates. The WordPress community is good about flagging issues quickly, and most plugin conflicts get resolved within the first week or two.

What you should not do is wait months. Deferred updates do not reduce risk. They compound it. Every week you wait is another week of unpatched vulnerabilities and another week of distance between your site's current state and where it needs to be. We break down exactly how those costs accumulate in the cost of deferred WordPress updates.

"Deferred maintenance isn't a cost saving. It's a deferred cost. Sites that haven't been updated in a long time always take the most work when we onboard them."

The "Update All" Problem

We see this pattern regularly: someone defers updates for weeks or months. The pending update count climbs. Then, at the worst possible moment, right before a big campaign or event, someone logs in and hits Update All.

"Update All is like crossing a road blind. You might make it, but you probably won't."

The problem is not just that something might break. The problem is that when something does break, you have no idea which update caused it. Was it the core? A plugin? The theme? If you updated everything at once, your only recovery option may be a full backup restore, and that means losing any content changes made since the last backup.

This is especially dangerous with plugins that modify the database during updates, like membership systems, e-commerce platforms, and event management tools. With those plugins, you cannot simply roll back the files. The database has already been altered, and it is now out of sync with the older plugin version. Recovery gets a lot harder.

When Update All Goes Wrong: A Real Example

We saw this play out firsthand with a professional association running WP Membership Pro. This organization had a complex plugin stack built around membership: a geolocation plugin, a mapping directory, member search, multiple subscription tiers with expiration management. The membership functionality alone depended on half a dozen interconnected plugins.

We had already flagged incompatibilities in their system and were developing an update strategy. The plan was to get through an upcoming membership campaign first, then tackle the updates methodically.

But the night before the organization launched a major communication effort to thousands of members, an employee who was not aware of the plan saw the high pending update count and hit Update All. WordPress core jumped a major version, along with everything else.

"The entire system became incompatible with itself."

Nearly every feature on the website broke. Because the membership plugin had altered the database during the update, a simple file rollback would not fix it. We had to do a full backup restore, and the client lost all campaign preparations made that day. Their launch had to be delayed.

It was a painful illustration of why WordPress core updates need to be run in isolation, why deferred updates compound risk, and why database-altering plugins are in a category of their own.

What WordPress Core Actually Controls

It helps to understand what actually changes when you update the WordPress core versus a plugin or theme.

WordPress core provides the foundation: user authentication, the database layer, the REST API framework, the block editor, media management, the taxonomy system, and the update system itself. It is the operating system on which your plugins and themes run.

Your plugins and theme control everything else: visual design, forms, e-commerce functionality, SEO tools, caching, security hardening, and backup systems.

When core updates, the risk of breakage exists at the boundary where plugins and themes interact with core functionality. The most common friction points:

• Deprecated functions
• CSS and JavaScript changes
• REST API modifications
• Block editor markup changes

This is why the right update order matters: plugin and theme developers test against the latest core version, so updating core first reduces the chance of conflicts.

The Security Case for Staying Current

In 2025, the WordPress space saw over 11,000 new vulnerabilities discovered. The vast majority, 96%, were in plugins rather than core. But running an outdated core version still creates real risk.

An outdated core means:

• Missing security hardening improvements that protect against entire categories of attacks
• Your PHP version may fall out of support
• Plugin developers stop testing against your version
• Managed hosting providers may eventually restrict your site

The commonly cited statistic is that over 70% of hacked WordPress sites were running outdated versions. The honest answer is that most of those sites were hacked through outdated plugins, not outdated core. But an outdated core makes everything around it more fragile.

Only the latest major version of WordPress is officially supported. There is no long-term support model. Previous versions may receive security backports, but there is no guarantee. Staying current is not optional if you care about security.

Frequently Asked Questions

What is the difference between a major and minor WordPress update?

WordPress uses a three-part version number. A minor update changes the third number (6.9 to 6.9.1) and contains only security patches and bug fixes. A major update changes the first two numbers (6.9 to 7.0) and introduces new features, editor improvements, and API changes. Minor updates carry very low risk and should be applied the same day. Major updates warrant more caution, including testing on a staging site if your plugin stack is complex.

Should I update WordPress core immediately when a new version is released?

For security and maintenance releases (the third number), yes. Apply them the same day. Vulnerabilities are exploited within hours of disclosure, so delay creates genuine risk. For major releases, there is no harm in waiting a week or two. That buffer gives plugin and theme developers time to release their own compatibility updates, and it lets the WordPress community surface any issues before your site is affected.

Is WordPress 7.0 a bigger update than 6.9?

No. WordPress does not follow semantic versioning, so the jump from 6.9 to 7.0 is the same kind of release as the jump from 6.8 to 6.9. WordPress simply counts upward. The first digit changing carries no special significance and does not signal a major architecture overhaul. WordPress 7.0 is scheduled for April 2026 and should be treated like any other major release.

Can a WordPress core update break my plugins?

It can, particularly with major releases. Plugins that deeply integrate with WordPress core, especially page builders, e-commerce platforms, and block editor extensions, are the most likely to experience conflicts after a core update. Security and maintenance releases rarely cause plugin issues because they change very little code. The safest approach is to update core by itself first, verify your site works, and then update plugins separately so you can isolate any issues.

Why should I avoid using Update All in WordPress?

When you update everything at once, core, plugins, and theme, you lose the ability to identify which update caused a problem if something breaks. Your only recovery option may be a full backup restore, which can mean losing recent content changes. This is especially dangerous with plugins that modify your database during updates, like membership and e-commerce tools, because rolling back the files alone will not fix a database that has already been altered.

When Professional Update Management Makes Sense

The framework above works well for individual site owners who have the time and discipline to handle every WordPress core update themselves. The reality is that most organizations do not.

We use an automated system called SafeUpdates that handles this across our entire fleet. It runs weekly updates, spins up a virtual staging server, applies them there first, runs automated regression testing, and pushes to production only if everything passes.

When something fails, our team is notified and investigates manually.

"Without an automated system tied into a large vulnerability knowledge base, you're not going to know when critical patches are released."

The important part is not the specific tool. The important part is that without that kind of system, you will not know when critical patches are released between your regular update cycles. Those mid-week security patches are the ones that matter most, and they are the easiest to miss.

Your job is to run your organization and advance your mission. Maintaining WordPress updates is our job. For a few hundred dollars a month, you can make sure your investment is well protected without it consuming your team's time or attention.

If your organization needs help staying current with WordPress updates, or if you have been deferring updates and are unsure where to start, our WordPress maintenance services are designed for exactly this.