Recap and proposal: align the WordPress release cycle with the industry standard

Welcome!

The WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:

Found a bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.? Create a ticket in the bug tracker.

Want to contribute? Get started quickly with tickets marked as good first bugs for new contributors or join a bug scrub. There’s more on the reports page, like patches needing testing, and on feature projects page.

Other questions? Here is a detailed handbook for contributors, complete with tutorials.

Following a lively conversation that happened in this blog in October 2020, here is the recap of the different ideas that were brought up and the proposal to move forward.

Rename phases

There is a consensus here.

Now	Change to
Phase 1: Planning and securing team leads	Phase 1: Preliminary Planning
Phase 2: Development work begins	Phase 2: Alpha
Phase 3: 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.	Phase 3: Beta (stays the same)
Phase 4: Release candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta).	Phase 4: Release Candidate (stays the same)
Phase 5: Launch	Phase 5: General release

Restructure Beta

The main point of discussion is what is allowed and what is not allowed during Beta.

Reserving Beta for testing and fixing bugs discovered by testing respects the efforts of the beta-testers by not introducing new bugs in areas they’ve already tested.
@azaozz

The wider software industry has done this work [how a release cycle is structured] for us. A mature software project is one that has a beta period during which the focus is on testing changes made during this release cycle to ensure its stability. Our current workflow means a random bugfix can go in ten minutes before RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). 1.
@johnbillion

However, there are concerns specific to our project

I worry that we aren’t allowing space for older bugs that aren’t specific to the planned features in the release. I also worry that by calling hard freeze earlier in the process we narrow the window for feature inclusion too much. I think Matt agrees with my thoughts there, as well.
@chanthaboune

My concern here is to not shorten the time allowed for fixing older bugs, which I see as an essential part of the project.
@sergeybiryukov

Proposed solutions

Adding a “Feature Freeze” period came up from multiple parties and it seems to be the most popular solution to allow contributors to focus on features first and defect work later, without doing the defect work in Beta, which should be reserved for testing.

Easier said than done… @hellofromtonya presented us with two solutions

Proposal 1: feature freeze and then do defect work

This proposal is for a feature freeze 2-3 weeks before Beta 1 and then allocation of this time period for defect work.

Pro

This proposal has a clear definition in the major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. cycle after the major release is kicked off and when the release squad is in place.

Concerns

It does not capitalize on the overlap between releases.
It does not provide a way to reduce the overall release cycle.
Does the major release squad need to be focused on the continuous defect work (i.e. defects not directly caused by the release)?

Proposal 2: defect work during release overlap

This proposal front-loads the defect work to overlap the previous release’s Beta and RC.

Pros

Work continues with purpose and focus while the previous release is in its testing and release phases. It capitalizes on the time between major releases while keeping the momentum rolling forward.
It provides an opportunity to shorten the overall major release cycle.

Cons:

Do we need the current release squad to be involved in this early phase or even in the defect cycle?
Could the component maintainers and CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Triagetriage The act of evaluating and sorting bug reports, in order to decide priority, severity, and other factors. Team work together to help prioritize and escalate defect work?

Branchbranch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". at Beta

In both solutions, trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. gets branched at Beta

Length of Beta

Both solutions beg the question: is Beta long enough? For 5.7 it’s three weeks. If the leadership of the project decides to move forward with one of the above-proposed solutions, WordPress 5.8 will have to account for a longer Beta probably. See:

Concern: We already have feedback that it’s hard to keep up with changes for our 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/theme authors. While a change like this is possible, it would require some paradigm shifts that I don’t think have been fully explored.
@chanthaboune

Call to action

Discuss this during the next dev-chat (January 13) and leave comments open for an additional week (January 20)
Present any additional evidence gathered to Josepha and Matt for final saying.

Thank you @hellofromtonya for peer review

Mark Parnell 9:16 pm on January 13, 2021

After the discussion we had in devchat, I think I’m in favour of proposal 1 over 2. Having dedicated time specifically focused on dealing with bugs in each release would hopefully mean more bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes which means better WP. And under 1 there’s no reason that bug fixes couldn’t still happen in trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision. during the 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./RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). phase anyway (since the current release will have already been branched). So it seems to me that 1 captures the best of both worlds.
Ebonie Butler 7:53 pm on January 14, 2021

I also feel that proposal 1 would be the best solution because it is the most straight-forward. There is immense value in keeping the workflow simple. Having a clearly defined phase just for bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixing within the currently relevant release cycle will eliminate any confusion and hopefully lead to less new bugs being introduced in the release.
Luke Carbis 10:10 pm on January 14, 2021

Proposal 1 feels better to me also. Simpler, cleaner.

“Does the major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope. squad need to be focused on the continuous defect work” – I think the answer is yes, if the release squad doesn’t focus on defect work, there’s a risk that nobody will ever want to.
Joe Casabona 11:34 am on January 21, 2021

I’m in agreement with the rest of the folks here. Proposal 1 is much clearer and I think aligns more closely with other software development practices. It lowers the risk of introducing new features that give devs less time to fix related bugs, and those who maintain/use WordPress to familiarize themselves with new features so close to an official release.