Drupal Release Cycle Improvements Inspired by WordPress and Other Platforms

drupliconTis the season for open source projects to work together and learn from one another. The Joomla community gave a warm welcome to Matt Mullenweg and Andrew Nacin at the Joomla World Conference, where Matt delivered a keynote address. This event opened up some interesting cross-platform discussions on development. The folks at WordCamp Miami are welcoming Joomla users and developers to attend their event next year in order to foster more shared experiences.

Leaders of the Drupal project are also looking to learn from other projects’ approach to development. Dries Buytaert, Drupal founder and project lead, announced today that the project will be moving towards a more agile development approach in order to deliver small changes faster.

Buytaert sites several issues with Drupal core development: “not innovating fast enough, insufficient commercial incentive to contribute, contributor burnout, and unpredictable release cycles.” Any living, breathing open source project will always have its own unique obstacles to overcome. While analyzing how Drupal’s current development approach can be improved, they compared and contrasted release strategies employed by other similar projects, including WordPress, Joomla, Typo3, Firefox, Ubuntu, Symfony and PHP.

The data collected shows that WordPress tends to iterate more quickly than others, putting out more major releases, but only offering security support for the current release. The difference here is that WordPress tries hard to never break backwards compatibility, even for major releases. Other projects surveyed may have longer waits between major releases with less emphasis on backwards compatibility but still maintain security support, or what they term LTS (Long Term Support), for older releases.

All have a substantive release anywhere from every 6 weeks (for Firefox) to 1 year (for PHP), with most at around 6 months. The projects differ in whether or how they provide LTS releases: Ubuntu does so once every two years and supports them for 5 years, while WordPress only provides security support for their latest release, but tries hard to always preserve BC, even in major releases.

Buytaert’s proposal to manage the Drupal 8 release cycle takes the best ideas from these projects and applies them in a way that will work for the Drupal community. They will be adopting a new strategy of mostly preserving backwards compatibility while aiming for an innovative release every six months, which is similar to most of the projects surveyed. At the same time, Drupal will be providing a single LTS release as the final minor release, similar to Joomla, and will support that LTS release until two additional ones have been released, in the style of Ubuntu.

The WordPress approach to release cycles is not the only way and it’s not the best way, either. It’s just the way that works for us so far. The tandem release cycle of WordPress 3.7 and 3.8 was a new approach for us, but it seems to be paying off big time. It’s exciting to see the Drupal community putting together a new strategy that will work for them, based on the strengths they see in other similar projects. The proposed changes seem to be well-received and it will be interesting to watch how this next release cycle changes things for Drupal folks.

2

2 responses to “Drupal Release Cycle Improvements Inspired by WordPress and Other Platforms”

  1. Since open source projects are different from traditional “competitors”, we get to see lots of great camaraderie like this between them. One of my dislikes about Drupal has always been the release cycle and accompanying breaking of backwards compatibility.

    While I understand that ignoring BC can allow you to make big changes more easily, it sure makes things harder on your user base. I have to wonder how many sites out there are still running on Drupal 6.x, or even 5.x, because site owners didn’t have the resources (expertise and/or money) to convert to a newer version.

    It sounds like Drupal might be taking an approach that will tone that down, while not discounting the possibility of BC breakage. Which I think is perfectly reasonable.

    It’s not like WordPress has never broken BC. I’m sure there are plenty of themes and plugins written years ago that would not function properly on the current core. We just break things much more gradually, usually by adding new functions, and deprecating old ones so that they still work (as much as possible), but spit out warnings in the logs.

    Anyhow, great to see some cross-pollination between projects!

Newsletter

Subscribe Via Email

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