Francesca Marano 5:04 pm on December 20, 2019
Tags:   

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 contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. are eager to move to a more frequent cadence.

Scope of the Working Group

To evaluate what is needed to change the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher versions
  • supporting fewer WP versions (for security and other things)
  • better E2E tests and vuln tests
  • Tide support
  • writing the announcements
  • writing the dev notesdev note Each important change in WordPress Core is documented in a developers note, (usually called dev note). Good dev notes generally include a description of the change, the decision that led to this change, and a description of how developers are supposed to work with that change. Dev notes are published on Make/Core blog during the beta phase of WordPress release cycle. Publishing dev notes is particularly important when plugin/theme authors and WordPress developers need to be aware of those changes.In general, all dev notes are compiled into a Field Guide at the beginning of the release candidate phase.
  • writing the field guideField guide The field guide is a type of blogpost published on Make/Core during the release candidate phase of the WordPress release cycle. The field guide generally lists all the dev notes published during the beta cycle. This guide is linked in the about page of the corresponding version of WordPress, in the release post and in the HelpHub version page.

Prerequisites

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!) TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. or GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ can be used.

Who is in?

Please drop your name, 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 SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. 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