Call for volunteers: Release Model Working Group

The topic of the release cadence has been brought up multiple times over the past year:

  1. The original post about Major and Minor Version Release Cadence – February 27, 2019
  2. Recap of Devchat after the hour: November 20 – November 20, 2019
  3. Tentative Release Calendar 2020-2021 – November 21, 2019

There seems to be a strong will to increase the number of releases per year and some exploratory work has been already done by multiple sources. Now it’s time to put it all together and move forward with a plan of action.

What problem needs to be solved

WordPress releases involve quite a lot of manual labor and testing so the releases right now can’t be more than 3, 4 per year. Core contributors are eager to move to a more frequent cadence.

Scope of the Working Group

To evaluate what is needed to change the Core release model in terms of procedures, cadence, resources and produce a report that will:

  1. Document the existing release process
  2. Evaluate the technical changes needed to speed up the release process
  3. Evaluate if those changes are doable with the existing resources and tools

What has been done so far

A few people have already done some research and told their experience during dev chats or in the above-mentioned posts, including in the comments.

In particular, some blockers have been identified and the working group aims to document all of them and find reasonable and feasible solutions. Here is a nonexhaustive list of things that have been mentioned:

  • scoping the release
  • putting together a release team
  • the process itself: automated, semi-automated, manual tasks
  • supporting fewer PHP versions
  • supporting fewer WP versions (for security and other things)
  • better E2E tests and vuln tests
  • Tide support
  • writing the announcements
  • writing the dev notes
  • writing the field guide


The team needs people with different skills and levels of expertise

  • A project manager/coordinator to make sure work gets done
  • People with commit and mission control experience to document the process of the release itself
  • People able to write E2E and vuln tests
  • People that worked in previous released and are familiar with the coordination part: from scope to release.
  • Historians! People that have been contributing for a while and are able to provide some background and context.
  • Anyone who is willing to help 🙂

Time commitment and frame

Between 2 and 3 hours a week, more if you want to!

By the end of 5.4 release the group should produce:

  1. A research of the various steps of the release
  2. An evaluation of the technical changes needed
  3. A draft of the feasible proposed changes

Communication and project management

I propose the group meets weekly in #Core and adopts a project management tool for the research phase – Trello would be my suggestion. Once it moves to build solutions (hopefully!) Trac or GitHub can be used.

Who is in?

Please drop your name, and Slack username in the comments if you are interested and how you think you can help.

Deadline: January 5. Hopefully, work will start on January 7th or 8th