Dev chat summary: August 21, 2019

Props to @francina, who led her first chat and will be the release coordinator for 5.3!

@marybaum is your chat reporter.


@chanthaboune kicked off the announcements with a comment that she’s working on a summary of the auto-update discussion from Tuesday afternoon.

Then she introduced @francina to the group, making the formal announcement that she’ll coordinate the 5.3 release.

Upcoming releases

5.2.3 to land on September 4

@francina took the floor to talk about planning for 5.2.3, asking @jeffpaul to report on his preliminary work, including two bug scrubs, one of which he led and the other of which @marybaum led.

Several people noted that as of those two scrubs, the release now has all of its tickets committed and merged.

As the discussion progressed into scheduling and the naming of release leads, @davidbaumwald pointed out that anyone, anytime, can schedule and lead a bug scrub.

@karmatosed noted that the Triage Team hoped to see more scrubs throughout the project, with more people leading them.

After some discussion, with the group showing a clear preference for new faces on minor releases, @whyisjake emerged as the release lead on 5.2.3.

His first official act was to confirm the preliminary schedule @jeffpaul had put together.

He also confirmed RC1 for Thursday, August 22, which did happen. (Go forth and test!)

You can find the rest of the schedule here.

Quote of the hour, from @whyisjake: “I don’t know if I’ve won the lottery or lost a bet.”

5.3 to land November 10

@francina referred the group to this post for 5.3 planning and scope.

Overall, the release will polish current interactions and make the UIs more user-friendly.

The release lead will be @matt; @francina will be the release coordinator. Other focus leads are in the post.

Three of the focus leads have yet to be named – but @chanthaboune will have those filled in the next week or so, well before the first beta on September 23.

In the chat, @justinahinon volunteered to lead Docs. @desrosj and @marybaum said they’d be part of his squad.

Triage lead @davidbaumwald announced a preliminary schedule of bug scrubs:

#1 8/27/2019 18:00 UTC
#2 9/5/2019 14:00 UTC  (EU-Friendly)
#3 9/12/2019 05:00 UTC (APAC-Friendly)
#4 9/18/2019 13:00 UTC  (EU-Friendly)
#5 9/25/2019 23:00 UTC  (Late-Americas-Friendly)

Which led into a discussion of triage and bug scrubs in general: that anyone can lead one; that several teams are using them regularly; and that it might be helpful to consolidate and promote a list of scrubs across the Project.

Open floor

At the ten-minute mark, @francina suggested group members introduce themselves so she (and the team) could get to know everyone a little better.

WordPress 5.3 Schedule and Scope

Following the open call for tickets and the planning roundup, we are ready to kickoff the release cycle for WordPress 5.3!


After checking with the focus leads, the proposed timeline is confirmed, as follows:

  • Beta 1: 23 September, 2019
  • Release Candidate: 15 October, 2019
  • General Release: 12 November, 2019


The focus will be polishing current interactions and make the UIs more user friendly.


  • Release Lead: Matt (@matt)
  • Release Coordinator: Francesca Marano (@francina)
  • Triage PM: David Baumwald (@davidbaumwald)
  • Editor Tech: Riad Benguella (@youknowriad)
  • Editor Design: Mark Uraine (@mapk)
  • Core Tech: Andrew Ozz (@azaozz)
  • Docs Coordinator: Justin (@justinahinon) + TBC
  • Marketing/Release Comms: Mike Reid (@miker)
  • Media/Uploader: TBC
  • Accessibility: JB Audras (@audrasjb)
  • Default Theme Wrangler: Ian Belanger (ianbelanger)
  • Default Theme Designer: Anders Norèn (@anlino)


At the moment of writing, there are 327 tickets open in the milestone:

Weekly Bug Scrubs

We will work our way through them via weekly scrubs

Proposed schedule will be discussed today, August 21st 2019, during the weekly Core chat. Ideally we will get assistance from component maintainers, that can help run specifically focused bug scrubs.

Let’s do this, ad maiora!


Proposal: Auto-Update Old Versions to 4.7

Foreword: To help anchor some of the main concerns from the comments, I’d like to highlight a few important points in this post. – Josepha

  • This post contains a careful roll out plan. This would not be be a sudden and un-communicated change.
  • There will be options for site admins to opt-out of the update with clear instructions starting 30 days prior.
  • This would apply to small segments of each version sequentially, not all at once. This helps us check the updates in batches and limit the risk of breaking sites irrevocably.

Based on the ideas in last week’s discussion, I’d like to propose a new policy regarding backporting security fixes to old versions, and a plan to implement it.


Note: This has been edited since it was published, to incorporate feedback from the comments.

Apply security updates to the latest 6 versions, and auto-update insecure sites to the oldest secure version.

That would mean that the currently secured versions would be 4.7 - 5.2, and the 3.7 - 4.6 branches would eventually be auto-updated to 4.7.

In practice, that’d provide roughly 2 years of security fixes for each branch, and roughly 10% of current sites would eventually be auto-updated to 4.7. Security fixes would not be guaranteed for any specific length of time, though. Once 5.3 is released, the oldest secured version would be become 4.8.

A set number of versions creates a consistent limit on the amount of work required to backport security fixes. Auto-updating insecure versions allows us to continue protecting older sites, rather than seeing them fall into the hands of spammers and criminals.

Implementation Plan

Auto-updating major versions is already a relatively safe process, because of WordPress’ commitment to backwards-compatibility, and the robust safety checks and rollback feature included in the auto-update system. However, this should still be done cautiously, to avoid breaking any sites.

A small subset of sites would be tested first, so that any problems can be identified and corrected before the majority of sites are updated. Sites would be updated one version at a time, to minimize the number of things that could go wrong.

Auto-updates of old branches would be done at a different time than new releases, to avoid a situation where there could be multiple problems to troubleshoot at once.

The process for auto-updating insecure versions would look like this:

Note: This has been edited since it was published, to incorporate feedback from the comments.

  1. Publish a post on, to inform the wider world about the upcoming updates as far in advance as possible. A specific date for updates will not be known at this point, but it will be at least 6 weeks in the future.
  2. Release 3.7.30 - 4.6.15, which will:
    1. Allow admins to opt-out of major auto updates by clicking a simple button.
    2. Email all site admins/editors to ask them to upgrade to the latest version, and inform them that their site will be auto-updated to 3.8 in the near future if they don’t opt-out. It will link to some documentation with more details, and include a link that they can click to opt-out. They’ll be warned about the security implications of opting-out. Editors won’t be able to directly install the update, but they can reach out to admins who can.
    3. Add an admin notice within wp-admin, containing similar information as the email. The notice will be visible to all site users.
    4. If users opt out, they will no longer get the emails asking them to update, but will continue seeing the wp-admin notices.
  3. Test auto-updating 3.7 to 3.8 against test sites, and make any necessary improvements to the auto-update system.
    1. One necessary modification would be to email the site owner if the auto-update fails and is rolled back to 3.7. The email should be a strongly-worded warning, letting them know that their site could not be upgraded to a secure version, and that they should manually update immediately. If they don’t update, it’s almost guaranteed that their site will be hacked eventually.
    2. Similarly, if the auto-update fails and the user is stuck on an insecure version, an admin notice should be displayed in wp-admin with a warning similar to the email above. This would replace the pre-release banner from 3.7.30 described above.
    3. We could potentially look into ways to make an educated guess about the chance of an undetectable error, and abort the update on those sites, to minimize the risk of breaking something. In those cases, we’d want to send the admin the same warning email & admin notice, letting them know that they’re stuck on an insecure version, and need to manually update immediately.
  4. Update the Core handbook with details on the new process, so that everyone knows how to deploy major auto-updates.
  5. Publish a document on explicitly stating a support policy, to avoid confusion.
    1. Only the latest major version is officially supported and guaranteed to receive security updates.
    2. There are no LTS releases, and all releases older than the current release are EOL.
    3. We make an effort to backport security fixes to the previous 5 major releases, but no guarantee is made, as sometimes it is not feasible or practical.
    4. Everyone is strongly recommended to always run the latest major version.
  6. T-30 days: Release 3.7.31, which will:
    1. Send all site admins and editors a 2nd email, similar to the 1st, letting them know that their site will be auto-updated to 3.8 in 30-45 days, and include instructions to opt-out, etc.
    2. Update the 3.7.30 wp-admin notice to include the date range of the impending update.
    3. Include any necessary improvements to the auto-update system, as described in step 3.
  7. Deploy the auto-updates in phases:
    1. The general process would be to deploy to a subset of 3.7 sites, then wait 1 week to see if any issues are reported. If anything unexpected happens, the process can be paused in order to fix those issues, and then restarted.
    2. T-0 days: Deploy to 2% of 3.7 sites.
    3. T+7 days: Deploy to another 18%.
    4. T+14 days: Deploy to the remaining 80%.
  8. If all goes well, the process can be repeated to update 3.8 sites to 3.9, and so on until all sites are running 4.7. Some of the steps can be automated to make the process easier in the future.


  • Overall, would you like to move forward with the general approach of this policy/plan?
  • Would you make any tweaks to improve it?

Update: The policy and implementation plan have been updated to clarify some miscommunications that were revealed in the comments:

Core’s official policy has always been to only support the latest version, and this proposal does not intend to change that. It only means to impact the number of versions that we backport to, and to start auto-updating very old versions to a more recent version.

This is consistent with — and moving towards — the Core team’s pre-existing long-term plan of getting to the point where all WordPress sites are running the latest version automatically and transparently, similar to how Chrome and other modern software work.

Older versions are not guaranteed to receive all security updates, since that is not always possible. The versions that receive updates would not be considered LTS versions; they would only receive the security updates that are feasible to backport. Everyone should always run the latest version.

This proposal is not intended to become permanent. It seems like a prudent action for the current situation, but like everything else, it should be re-evaluated in the future, as the situation changes.

#auto-update, #security