Yesterday, Francesca Marano opened a proposal for changing the phases of the core WordPress release cycle. It was a recap of a discussion the began in October 2020. The goal is to align the platform’s phases with the larger development industry standard.
Aside from naming, WordPress has mostly followed the software industry in how it tackles its release cycle. Following a well-known convention can make it easier for developers outside of the WordPress ecosystem to transition into it. It would also allow developers to follow cycles of other projects, many of which are WordPress dependencies. This sort of standardization is generally viewed as a good thing throughout the software development world.
Based on the ongoing discussions since October, there is a consensus on renaming the phases to align with the standard. The following table shows what each phase would be renamed to:
PhaseCurrent NameProposed Name1Planning and securing team leadsPreliminary Planning2Development work beginsAlpha3BetaBeta4Release candidateRelease Candidate5LaunchGeneral release
However, this is a two-part proposal. Simply renaming the phases does not change how the release cycle works. To follow the standard strictly, WordPress would need to change when code is committed too.
How To Handle the Beta Phase
There is one point of contention with how to handle the Beta stage. The standard calls for no additional code changes other than new bug fixes introduced earlier in the cycle. For the WordPress project, this creates a problem.
WordPress will be 18 years old this year. Over the years, it has racked up a ton of older bugs. These are often fixed later in the cycle, sometimes during the Beta stage. These older bugs may not have been a part of the Preliminary Planning phase, but does that mean they should wait until the next release to go in? Strictly following the proposal, they should be