Dion Hulse 3:12 am on August 11, 2025

Plugin Rollout: Phased Releases

Through #8009-meta we’ve started work on adding Phased / Staged pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party releases to plugins utilising Release Confirmation.

What is phased releases? In short, this allows for your plugin update to be released to a smaller subset of sites prior to full release to all sites.

Why would you want to use it? Sometimes plugin updates can inadvertently break user workflows or run into conflicts with other plugins. Often these issues are not known until after a plugin update is released, and lots of users have already installed the update, this allows for a short timeframe where hopefully engaged users will report issues to you sooner.

How? Initially this has been limited to plugins using Release confirmations. This means a plugin has to explicitly opt-in to using this feature at the time of the plugin’s update release.
To start with, only one strategy is offered, Delay Auto-updates for 24 hours – This disables the WordPress plugin automatic updates for the first 24 hours of a plugin release. Site Administrators can still click on “Update” to install the latest version, as it’s hoped that these users would spot any issues that result from using the updated version.

Release Confirmation showing a rollout strategy selection. — Example of the Rollout Strategy selection included in Release Confirmations.

Technical Limitations

To ease the potential of user confusion, this has been initially launched focusing on disabling automatic updates, rather than disabling the update entirely for a WordPress site.
Currently WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ can only instruct WordPress 6.6+ sites not to automatically update the plugin.
Currently WordPress.org can track the number of plugin updates (Through the Active installs / Active versions statistics), but can’t differentiate between a user-initiated/manual update and an automatic update.
It’s up to 3rd-party update tooling to respect the WordPress 6.6+ flag to disable automatic updates, it’s unknown whether any of these tools respect it. Anything that runs the WordPress Automatic updater should support it.

What will future iterations bring?

What functionality is offered here will heavily depend upon author feedback in using the feature, or what would encourage them to do so. Examples of what this could be include..

Strategies that rollout updates to a percentage of sites. For example, 1% per hour, or gradually increasing to 20% over 3 days and the final 80% on day 4.
Improvements to find out if there’s been any issues reported in the update. For example:
- Are plugin reviews overly negative?
- Have any PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. https://www.php.net/manual/en/preface.php. Warnings/Fatal errors been reported automatically (not implemented)
- Have WordPress updates been rolling back to their previous version (in the cases of fatal errors)
Statistics of how many sites have updated to the new version. Could be a rounded number (like the existing Active Installs) or simply a percentage (like the Active Versions chart). Eg: Plugin: 100k Active installs; Latest version: 80k+ or 80%.

Questions for Plugin Authors

Do you plan to use this feature? If not, What would convince you to?
What improvements would you like to see?
For example: What strategies? What additional information? What would tell you your plugin update is a success?
Would you like to see manual/user-initiated update availability also disabled?

Thank you to the handful of plugin authors who have already made use of this feature.

Edits: An image of the UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. added a few hours later.

Alexandru Tapuleasa 3:42 am on August 11, 2025

This would be an excellent tool! Rolling out the update to just 10-20% of the sites in the first 24-48 hours is a good strategy to decrease breaking updates.

Maybe admins could also have an option to “enable rollout/betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.” auto-updates. On the other hand this might end up filling up the % of rollout websites without any actual feedback.

Also, maybe pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party authors should have a way to flag “non-reversible” updates (that make database or file changes) where you can’t just drop back to the previous version and you should backup your website before.
- Dion Hulse 5:21 am on August 11, 2025
  
  an option to “enable rollout/betaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process.” auto-updates.
  
  Importantly, It should be noted that these releases are not beta versions, it’s intended that this is a final/stable release. A beta release is designed to “not be for production use and may have bugs”.
  
  this might end up filling up the % of rollout websites without any actual feedback.
  
  That’s my thought. For example, if a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party adds a BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. to the editor, and the site owner publishes every Wednesday and Saturday, but the update came out on a Sunday, they’re not going to notice the broken behaviour until they attempt to publish on Wednesday.
  Whereas, if the site owner saw an update and installed it on Monday, they’re more likely to then check that their site is still operational and that the Block works.
webaware 5:05 am on August 11, 2025

Very good idea, only allowing auto-update sites to see updates in first 24 hours is a great start and likely good enough for most of us. Albeit, many of those auto-update sites will not be actively monitored by their owners, nevertheless it will allow for some feedback if an update breaks things.
Having the ability to enable phased releases from the Release Confirmation UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. would be great.
From the other side of the fence, sometimes a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party update triggers some work for site maintainers and the preference is to get that over and done with across all relevant sites. I see this with Gravity Forms updates, a plugin that already supports phased releases. I notice the update on one or more sites, download the update and check to see what impact it will have. If there’s, say, styling fixes to be made, I’ll want to be able to churn through affected sites straight away. With Gravity Forms, one can force the release check by visiting the system status page, so I can update all sites whether or not they saw the phased release.
I don’t know whether that can be accommodated through the “Check again” link on the WordPress Updates page, but it could be handy if it’s possible.
- Dion Hulse 5:14 am on August 11, 2025
  
  many of those auto-update sites will not be actively monitored by their owners
  
  I think you’ve misread it, currently the option offered is “do NOT auto-update” for 24hrs, such that initial updates are going to be from users who are maintaining / using their site at time of update.
  
  one can force the release check by visiting the system status page, so I can update all sites whether or not they saw the phased release.
  
  This is why I’ve started with only disabling auto-updates to start with, if a release fixes a bug that a site owner has been experiencing, I want them to be able to immediately install that update on all their sites.
  I feel that a user seeing an update available on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/, and in SiteA but not in SiteB would cause confusion.
  - webaware 5:37 am on August 11, 2025
    
    Sorry, yes, I had it straight in my head on first reading, but {{the usual distractions}} meant that it somehow flipped. Good, good!
    If the phased release mechanism later evolves to offer percentages of websites the release, it would be handy to force getting the release notification via “Check again” if that’s possible.
    - Dion Hulse 7:11 am on August 11, 2025
      
      it would be handy to force getting the release notification via “Check again” if that’s possible
      
      That’s a reasonable workaround! At present it’s not possible, but a minor modification to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. could be made to make it work.
Dennis Bareis 5:41 am on August 11, 2025

Staged roll out great idea, I’d like to set the length of the rollout, users should be able to manually update and perhaps set how much risk they are willing to take with updates like Microsoft does (be first or lastish)
- Dion Hulse 7:09 am on August 11, 2025
  
  I’d like to set the length of the rollout
  
  @dbareis What kind of length of time do you think you’d want to use? And in what shape, Just disabling automatic updates for X days (1? 2? 3?), a constant increase (ie. 1% per hour), or a logarithmic (eg 25% over the first 3 days, the remaining 75% over the next day)?
  - Dennis Bareis 9:20 am on August 11, 2025
    
    Slow start rollout over maybe 2 weeks
Robin W 6:05 am on August 11, 2025

Wow ! Great idea, yes would use it.
Those who update manually tend to be the ones who will a) update early, b) know what updates they have done, c) look at what the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party fixes/adds and test that
They are the ones that report issues to me typically within a day, so that would mean I can iron out any issues before the majority get the update.
OllieJones 2:07 pm on August 11, 2025

Yes, I will use whatever you guys come up with. It’s a great idea to limit the blast radius of a broken pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party update. Thanks.

My only suggestion? Keep it simple and easy to understand.
Neil Murray 8:24 am on August 12, 2025

Do you plan to use this feature? Yes
What improvements would you like to see? None at this stage. Looks OK for an initial trial.
Would you like to see manual/user-initiated update availability also disabled? No.
Josh Kohlbach 12:33 am on August 13, 2025

This is fantastic Dion @dd32!

We will definitely make use of this, especially on our plugins that have a larger active install base. We were actually just discussing this internally yesterday so I was surprised to see this post!

I think giving the committer ability to configure the %ages for the rollout would be handy. For example, most often we would just set 20% on day 1 and the remaining 80% on day 3 to make sure things are stable for a full 24hr period (accounting for timezones) before rolling out the entire release.

Another request, and I’m not sure if this is something that would be considered since active install exact counts are private currently, but being able to see how many people on each version would be amazing. If thats not possible, seeing how many people out of the % set have actually updated would be a great second.
csforwp 5:42 pm on August 18, 2025

I would love to see this addition. Something that would make it more appealing to me would be the ability to invite specific users to upgrade. This would allow for granular control over the release without having to install the pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party manually via zip.
Rebecca Markowitz 12:21 pm on September 1, 2025

This is a really exciting development! Thank you to everyone who has been working on it. Gradual rollouts will be a huge step forward for pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party stability and user trust, and we’re very appreciative of the effort that’s gone into making this possible.

From the perspective of a large-scale plugin like Elementor, we wanted to share a couple of thoughts. In the current design, only plugin committers/admins can manage these phased releases. For security reasons, we keep that group very small, which means every release would need to be funneled through just a couple of people. That creates a bottleneck that makes it difficult for us to realistically use this otherwise great feature.

One idea that could help would be to introduce a dedicated role, such as “Release Manager,” who would have the specific ability to create and manage phased rollouts, without having the broader and higher-risk permissions that committers have (like deleting plugins).

Additionally, it could be very valuable if release managers had the ability to stop or freeze a rollout during the 24-hour timer window. This would give teams a chance to pause a release mid-rollout if issues surface, before it reaches all users.

We’re really grateful for the work being done here, and we hope this perspective from the large-plugin side is helpful as the feature evolves.