Drupal development snapshots puzzingly rebuilt

Thu, 03/10/2013 - 14:22 -- James Oakley

Please Update

Earlier this week, I got several automated e-mails from Drupal sites I manage. The e-mails told me that some of the modules I use had a new version, so I was advised to log in and upgrade.


I was puzzled to see that one of the modules I maintain was in the list of pending upgrades. That was puzzling because I hadn't pushed any changes to that module for a little while, so I wasn't expecting any new releases.

A quick look at the module page on Drupal.org confirmed: No, there weren't any new point releases (7.x-1.3, etc.). Yes, my website used the --dev release (7.x-1.x-dev). And, yes, the last modified date on the development snapshot for the module was 1st October 2013.

That would normally only happen if I've pushed some patches to the repository. So I checked the commit log for the project, and also the repository viewer. Nothing had changed.


So, for some reason, the Drupal packaging script had repackaged my module's development snapshot, even though no code had changed. This has never happened before, and it hasn't happened since. (Development snapshots are automatically rebuilt every 12 hours if necessary, so there have been a few chances since then for this to repeat itself).

Closer inspection showed that every module that needed updating, on every Drupal site that sent me those e-mails, was using the development snapshot not a tagged release. It seems that every (most? / some?) Drupal modules have had their development snapshots rebuilt, even though there have been no changes.

I have searched on Drupal.org, and not found any other mention of this, and certainly no explanation. If anyone knows what happened, please comment below.


In the meantime, it was time to update these modules to the latest version. Although nothing had changed, if I didn't do this I'd carry on getting reminders. Those reminders would become white noise, and I'd end up ignoring them, which would mean I then wouldn't notice a genuine update later.

I use Drush for updating. If you've got these e-mails, please be careful, because I have found forum threads on Drupal.org from people who went wrong here.

By definition you are using the development snapshot. Drush will default to updating you to the latest tagged release. So don't type

drush up

... or

drush dl module-name

That would overwrite yoru development snapshot with the latest tagged release. The chances are that you are using the development snapshot because you quite deliberately don't want the tagged release - you need a fix that's been committed since then.

So you need

drush dl module-name --dev
drush cc all

There's one final gotcha. One of the projects I had to update was a base theme. I was using the develoment snapshot on the 7.x-2.x branch, because I needed something that had been fixed since the last release on that branch. Since then, the maintainers have forked it and there is now a 7.x-3.x branch too. My subtheme may well not work as expected with the 7.x-3.x branch. The time will come to move across, but I'd want that to be a planned move.

So, in that case, it had to be:

drush dl module-name-7.x-2.x


drush dl module-name --dev

would have given me the 7.x-3.x development snapshot instead, which would have been interesting.

Blog Category: 


Codi Lechasseur's picture

The drupal.org infrastructure team forced a rebuild of every dev project on Tuesday whether there was a code change or not. Not sure why they had to, but packaged dev releases were throwing 404's until the rebuild completed.

Ian Thomas's picture
Submitted by Ian Thomas on

Or even better, switch to a drush make-based workflow. That way you put the exact version numbers of all your dependencies in the .make file (including the git hash if it's not a packaged release) so it's easy to see what you're running. Any changes to core or modules need to be written as patch files, so you can't accidentally forget that you've hacked core (not that you'd do that) and lose your changes in an upgrade. Ideally those patches are also uploaded to the drupal issue queue and checked in the by the maintainers.

If you don't want to move to a fully make-based process, there is also drush remake, which when you use the --projects= flag will update a project or two in place (similar to doing a drush dl, but with the version you're after recorded in a file that you can store in version control).


Add new comment

Additional Terms