Cancel

Sarah Gooding

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:

  1. A long term roadmap (theirs is 6–12 months) outlining major themes and features.
  2. 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.
  3. Regular project triage, with release priorities managed at the team (i.e. Component) level.
  4. Documentation integrated into the development process.
  5. Automated testing of releases and upgrades.
  6. 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.”

Category: ,
Tags:
12

12 responses to “WordPress Contributors Propose Shorter, Time-based Release Cycles”

  1. A monthly or even semi-monthly major release schedule would move WordPress from being a useful tool to being a coder’s toy. While coders are understandably anxious to see their work distributed, users primary desire is for stability and reliability. We really don’t care much about WordPress, what we care about is our mission. We know that every update puts our mission in peril. Our ideal update is installing a well-vetted year-old version that has undergone a series of bug-fix updates with no new features added. We also want to know that when we go through the troubles of updating we will be rewarded with something worthwhile. Time-based updates would be the opposite of this. Update in haste, repent at leisure.

    Create forum topic from comment

    • Precisely. All this rapid release cycle seen so often for years now led to a lot of broken releases and update fatigue for users and admins, for very good reason, since even if it does work well you don’t even have time to get used to something because it changes again.

      Create forum topic from comment

      • Yeah, and of course it WP is updated often, then also many plugins need to adjust and release updates more often to stay compatible. That will be a nightmare to site owners who will need to perform updates every two days or so, as different plugins release their updates at different times.

        So from a user (and not a developer) perspective – a big no to the idea.

        And I guess plugin developers would probably also object the idea, as it puts more burden on them.

        This seems to be good only to the code geeks at the WP team.

        Create forum topic from comment

    • Agreed. When I tried to point this out I was met with “well, just don’t update.” Core seems to not understand the full scope of their user base and that there is a sizable audience of users who have to have stability over “new shiny”. If WordPress officially supported an LTS branch, then this would be an acceptable answer. But considering the only branch that is officially supported, and considering that security updates are often mixed in with both minor and major update releases, the only way to ensure your site is not vulnerable (in terms of issues in core) is to always update to the latest version.

      I understand that they want to rapidly iterate the components related to Gutenberg but then just lends support to keeping Gutenberg as a plugin and not incorporated into core.

      Create forum topic from comment

      • Core seems to not understand the full scope of their user base and that there is a sizable audience of users who have to have stability over “new shiny”

        They know that this type of users does exist, but simply don’t care about us. We are more of a nuisance than a value to them.

        Create forum topic from comment

  2. As a consumer, I much prefer shorter release cycles.

    Gutenberg 4.7 was released December 13.

    But due to WordPress’ long release cycles, we are still using Gutenberg 4.7 in WordPress 5.1, despite that Gutenberg has since released 4.8, 4.9, 5.0, and 5.1.

    In fact, Gutenberg won’t be updated in WordPress Core until WordPress 5.2, which doesn’t ship until April 30. By that time, Gutenberg will be at approx 5.5 – but again, WordPress will be shipping something more like 5.2.

    Shortening the release cycle can only be helpful!

    Create forum topic from comment

    • That view doesn’t make sense if you want a stable experience. The version that ships with 5.2 won’t be Gutenberg 5.2. it will be the feature set of Gutenberg 5.2 with all of the bugfixes found over the course of a feature-freeze period.

      Feature freezes are part of any mature software release schedule, and they should be long enough for many edge cases to be explored and bugs to be eliminated.

      You are essentially saying “I want to run the nightly snapshots on live, because they have cool features!”, But that’s not how you release code to millions of users. That’s why the Gutenberg plugin still exists. If you want the bleeding edge features, and don’t mind increased instability, just install it and go on with your life.

      The rest of the public should get well-tested, safe software.

      Create forum topic from comment

  4. I don’t want major changes every few weeks, but I’d be happy with big fixes coming through regularly.

    As somebody who supports a number of sites for clients, some of them very twitchy about the risk of things breaking, I’m not convinced a shorter cycle is a good idea. There’s work involved in every release, making sure we aren’t about to take a client’s site down by releasing.

    Not all releases are as big as the 5.0 release was. In fact, I think WordPress could do with more clarity over major/minor releases. 4.9 was not a vast change over 4.8; 5.1 was not a vast change from 5.0. They were both labelled “major”, but, since they introduced potentially breaking changes, but were relatively small. In contrast, 5.0 was a MAJOR change, that did need us to make changes to our code to prevent breaking client sites.

    Create forum topic from comment

  5. A monthly release cycle seems like huge overkill, imho. I feel a quarterly release cycle seems to be a sensible balance, with security fixes/bug fixes as warranted. I really don’t think a vast number of users are clamoring for frequent updates (though I do understand the perspective of the post here about Gutenberg being out of sync). And when you add plugin updates into the mix it becomes a non-stop update management time waste.

    It seems to me that a large percentage of users break down into two groups.

    The first being those that read this site — developers and the like. From my perspective as a dev and a business owner, I wish to keep my sites stable and working and don’t need more frequent updates. I need stable updates with enhancements…but I’m not itching to add the next “shiny feature”. Robustness and keeping the revenue coming in is what is important to me. I don’t want to spend more time chasing updates (though I understand I can ignore them, as I have with 5.0 at this point).

    The second being the more casual and less web-dev savvy end user. I manage several sites for people or artists who are business owners and not web programmers. They do appreciate new functionality, but are often confused by updates and have had experiences where installing updates does break compatibility with plugins, etc. They don’t seem to be clamoring for more frequent updates either In my experience, these users also want a stable experience and don’t need more “admin” tasks to deal with. (lets not argue about whether these people make good or bad admins — the fact is there are thousands of these types of end users out there using WordPress).

    I know this is anecdotal, but I don’t see either of these groups clamoring for more frequent releases. The idea of more frequent updates seems like a solution in search of a problem to me. For WordPress, the customer/client is the end user — not the developers — and that’s what and for whom decisions should be based upon. The three main benefits listed in this article don’t really change things or improve things all that much for an end user.

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.