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:
| Phase | Current Name | Proposed Name |
|---|---|---|
| 1 | Planning and securing team leads | Preliminary Planning |
| 2 | Development work begins | Alpha |
| 3 | Beta | Beta |
| 4 | Release candidate | Release Candidate |
| 5 | Launch | General 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 put on hold.
It would also introduce a hard freeze on any enhancements set for the release but incomplete.
“I worry that we aren’t allowing space for older bugs that aren’t specific to the planned features in the release,” wrote Josepha Haden in a comment on the initial discussion. “I also worry that by calling hard freeze earlier in the process we narrow the window for feature inclusion too much. I don’t like limiting ourselves to feature specific bugs right now, since that excludes so many of our volunteer contributors. It’s harder to work on features since they are complex and fast-moving, and older bugs present more opportunities for casual contributors.”
On the flip side, there is potential that a bug fix could introduce new, unforeseen bugs. The later it is added during Beta, the less likely such bugs are noticed before the General Release phase. Waiting for the next cycle provides more time for testing.
One of the benefits of this system is that almost no new bugs would be created during Beta. This would allow volunteers to shift more efforts to testing and fixing issues that emerged in Alpha.
WordPress has always marched to the beat of its own drum. It can more closely follow standards while breaking free from strict confines when it makes sense to do so for the project. Beta-stage bug fixes not intended for a particular release could be handled on a case-by-case basis. We have people in leadership positions who are capable of making these calls when they arise. With automatic updates for minor releases, I am less concerned about late-stage bugs.
Tonya Mork proposed two solutions for defect work to continue in and around the release cycle. Both would require that WordPress branch off at Beta, providing contributors an avenue to push forward fixing bugs.
The first proposal calls for an earlier feature freeze, providing two or three weeks before Beta 1. This period at the end of the Alpha phase would be solely dedicated to defect work.
The second solution moves this defect work to overlap the previous release’s Beta and Release Candidate. This allows work to continue during the time between major releases. It could also shorten the overall major release cycle.
This second solution is also consistent with Joost de Valk’s thoughts on handling defect work. “I think we should just branch off earlier, and keep trunk open for normal business,” he said on the proposal. “That way, everything can be worked on all the time, but it won’t be included in the next release depending on when you commit it. That’s fine, every piece of open source software I know in the world works like that, except for WordPress.”
Many plugin and theme developers already find it tough to keep up when changes drop in the Beta or Release Candidate phases. Having a clear and defined point where changes land will benefit the extension ecosystem, also helping end-users in the long run. This second solution would do that.
There is nothing wrong with combining both solutions either. Since the plan would be to branch off at the Beta phase, the second solution is already in place by the act of branching. The real discussion is over whether the project should dedicate a block of time during its Alpha stage that focuses purely on bug fixes.
Comments on the proposal are open through January 20 before moving toward a final decision.
The next proposal: semantic versioning, anyone? Anyone? Is this thing on?
I have another idea – since each Gutenberg release does have some sort of bug fixes, performance improvements, over just new features, it would make more sense to actually integrate an always-updating Gutenberg release as an option inside WP without having to uninstall the plugin. In my opinion that would expose an extreme amount of users to the block based editor and with a special feedback based system it could give devs direct access to feedback and analytics [if enabled] to the devs from the actual users.
In my opinion that would extremely speed up the development of Gutenberg.
Everything should be opt-in of course. I can’t count the number of people that don’t know that installing the Gutenberg plugin would give them an always updating version.