WordPress Contributors Propose Shorter, Time-based Release Cycles

  • Home / Search engine / WordPress Contributors Propose…

WordPress Contributors Propose Shorter, Time-based Release Cycles

WordPress release cycles may soon take a more predictable cadence, as contributors are considering moving to a time-based approach. The discussion began during a recent core dev chat in mid-February when Gutenberg phase 2 lead Riad Benguella proposed the project move to shorter, automated release cycles.

The Gutenberg team has successfully been releasing a new version of the plugin every two weeks on schedule and any features that aren’t ready are postponed to the next releases automatically. Benguella contends that this type of release schedule has the potential to bring several benefits to WordPress:

Less stress for contributors

Predictability: People can plan around the release timelines easily

No delays as releases are not feature-based

Shortening major releases may prove more challenging for WordPress, which is at a much larger scale than the Gutenberg plugin. The plugin also has the added advantage of being able to manage releases and development on GitHub.

“I think there are a lot of infrastructure problems that need to be solved for WordPress before we could move to a fast, automated release cycle,” Gary Pendergast said.

“Having a major release once a month is achievable, it’s something I’d like us to get to, but the release process is too manual to have multiple releases running at the same time at the moment.”

Jonathan Desrosiers drafted a proposal that summarizes this discussion and outlines some of the manual tasks required for getting a major release out the door. These include time-consuming tasks like Trac gardening, creating a Field Guide, blog posts for the betas, RCs, and official release, documentation updates, videos, dev notes, and other items that are often completed by volunteers.

The 3-4 month release cycles that WordPress had from versions 3.9 – 4.7 allowed for all of the administrative overhead outlined above to be completed in a reasonable amount of time, but the general consensus is that some of these tasks could be more simplified and/or automated.

Desrosiers highlighted several benefits of moving to a shorter major release cycle, including less drastic change for users that might ultimately result in more users being comfortable enabling automatic updates for major releases. Detriments to shortening the release cycle are the increased burden it puts on volunteers as well as theme and plugin developers who need to push compatibility releases. It would also introduce more backporting work for security releases.

Several contributors have left feedback on the post with insight gleaned from other projects’ release scheduling. Jeremy Felt reviewed Firefox’s release owner table that assigns leadership and dates for several releases in advance.

“I think getting to a shorter release cycle in general will involve scheduling multiple releases and assigning their release leads in advance,” Felt said. “So far most of our scheduling is done as soon as the last release has been shipped.”

Joe McGill examined VS Code’s development process and found several similarities to the process he thinks WordPress could adopt in the future:

A long term roadmap (theirs is 6–12 months) outlining major themes and features.

A monthly release cadence based on 4 week sprints which begin with milestone planning and always results in a release of whatever was completed in that monthly iteration.

Regular project triage, with release priorities managed at the team (i.e. Component) level.

Documentation integrated into the development process.

Automated testing of releases and upgrades.

Only important regressions and security issues are handled in minor releases between monthly milestones, everything else is moved forward to the next release (or reprioritized in the backlog).

Several of these points echo feedback from other contributors who have identified documentation integrated into development and automated testing as ways to speed up major release cycles.

“If we don’t have the infrastructure and tooling to support a 1 month cycle, then I think we could attempt a 2 month cycle with a goal towards moving to shorter cycles,” McGill said.

The Gutenberg plugin’s relentless pace of iteration and predictable release cycles have opened up a world of new ideas for improving the process for WordPress core. Discussion around moving the project to shorter, time-based release cycles is still in the preliminary stages. No major changes have been agreed upon yet, but the process of exploring different ideas has put the spotlight on tasks that could afford to be tightened up in the release process. This falls in line with WordPress’ 2019 theme of “tightening up.”