Details about the new Drupal 6 release process

Ever since Drupal uses major versions for compatibility changes and minor versions for bugfix and security updates (since Drupal 5), it was most often the case that a new minor Drupal release included bugfixes and security fixes packaged into one update.

The process to bundle bugfixes and security fixes into one was so common that the Drupal 6.17 release that did not include security fixes but only covered bugs was a grand surprise to many people. We have even seen "security researchers" who ran automated version detection scripts, and considered sites not running 6.17 insecure. That a Drupal 6 release would include security fixes is that strong in the minds.

Most Drupal 6 releases however included numerous other changes. These in an ideal world do not affect your site and will only fix stuff rather then breaking anything. However, sometimes people find that the bugfixes result in side effects we did not think beforehand. Therefore sites where quality assurance (QA) is applied take time to ensure the new update do not break existing functionality.

To help people roll out security fixes without the requirement for lengthy QA cycles, we followed the tradition to make patches available (see for example SA-CORE-2010-001). These patches let site admins to quickly fix the site while the other fixes are in testing. However, running a patched Drupal is not for everyone, it should be done with careful attention. It also obscures Drupal 6's update module processes, since your site will tell you a security update is available, until you actually deploy the full thing.'s usage tracking will see you are running an insecure version. Automated bots and script kiddies will register your site as insecure and attempt to run exploits. If you do not apply the patch however trying to stay away form killing kittens, your site will actually stay insecure.

So if you do not update to the security release, it's bad for everybody. If you do apply the patch but not the full release with bugfixes, it's bad for many reasons. Ideally, Drupal would provide an official release with the security improvements only, so you can choose to use that only and maybe later upgrade to include the bugfixes.

That is what the Drupal Security team discussed and arrived to at Drupalcon San Francisco. The decision was to make available actual security-only releases as well as a security plus bugfix release. This now makes it possible to just deploy the security fixes as soon as possible, without maintaining a Drupal fork. Then - given the usual timeframe of Drupal releases - you'll have plenty of time to review the other bugfixes and ensure they'll not affect your Drupal website in any wrong way. (Not that its expected that bugfixes could break your site, but it does happen).

This new process is applied first to Drupal 6.18 and 6.19 which were released at the same time. We tried to explain this new concept in the release announcement and the security announcement respectively. We hope this will help in rolling out security fixes quicker and that this new process is well received.

You can hear more about Drupal security at Drupalcon Copenhagen at the Drupal security - configuration and process session and at Drupal security for coders and themers.

The Drupal Security team can be reached at security at or via the form at



dalin's picture

So how does this work from

So how does this work from you the committer's point of view? Do you wait on committing bug fixes till after the security release has been tagged? or do you maintain a separate short-lived branch? This would of course be easier to do with Git, but how do you pull it off with CVS?

Add new comment