Our Plans for Drupal Upgrades

By:

on

June 17, 2008

We had some feedback from a client earlier this week who was worried about adopting Drupal now because she was told that there was going to be a new release out soon that would make the previous ones out of date. I figured that it was important to convey OpenConcept's approach to Drupal upgrades so that it is possible for organizations to budget for future expenses.

Now Drupal is a great software project, but like all software projects it gets out of date rather quickly. Because there is an active developer community and the Internet is such a corrosive environment there will inevitably be upgrades that are required.

There are regular security patches that come out a couple of times a year when a problem is identified by the security team, but these generally can be done without affecting the functionality of the site.

It is the major version upgrades though that are going the focus of this post, because the major version upgrades are generally more predictable and more expensive than the smaller security upgrades.

When I was at the last DrupalCon in Boston there were quite a few people discussing approaches to upgrades. Every Drupal developer has sites that they know they will have to upgrade, so it is something that we all want to be as easy as possible. For simple sites (Drupal Core) the upgrades are usually quite straight forward, but for more complex sites they aren't.

The Drupal community is hoping to put out a major release on a 18 month release cycle. The last release was in January of this year, which puts the release of Drupal 7 to July 2009. At the moment most of our sites are running Drupal 5 even though Drupal 6 was released six months ago. This is fairly fairly standard in the community.

When Drupal core is released and when the contributed modules are
updated to that release are also different things. Some important modules have yet to be released with Drupal 6. We have launched a Drupal 6 site recently, but need to carefully evaluate a client's needs before doing so. I don't expect to be launching clients sites with Drupal 7 until the end of 2009. That being said there will be some great new features that will be available in Drupal 7 and we will want to be using those as soon as it is practical to do so.

Drupal 5 will remain a supported release until at least the first stable release of Drupal 7 in the summer of 2009. Given the number of Drupal 5 installs and modules it will probably be supported for longer.

If your site is presently using Drupal 5 we would expect that you would want to plan for an upgrade to Drupal 7 in late 2009. We would need to evaluate the client's needs when considering the upgrade, but we feel that it will be the most cost effective and least disruptive for our clients to skip major releases. If there is something that is available in Drupal 6 that the client is eager to adapt we would want to consider back-porting the functionality and doing the upgrade.

There will be an upgrade path for Drupal projects. Not all modules will be available between versions, and it may be important to consider if all of the upgraded modules are required. Drupal 5 still offers the broadest, best supported and tested platform for this CMS. Drupal 6 is quickly providing the full feature set, and there will be a slightly different set of contributed modules available for both 5 & 6.

The web is a pretty rapidly changing environment, they say that 1 solar year is equivalent of 3 web years. Organizations should plan on doing major version upgrades every 3-4 solar years with any CMS (or once every web decade). Depending on the complexity of the site to be upgraded, a major version upgrade could end up being as expensive as the initial site development. Fortunately, organizations don't have to follow every major version release, as for most of us this isn't required.

About The Author

Mike Gifford is the founder of OpenConcept Consulting Inc, which he started in 1999. Since then, he has been particularly active in developing and extending open source content management systems to allow people to get closer to their content. Before starting OpenConcept, Mike had worked for a number of national NGOs including Oxfam Canada and Friends of the Earth.