In a busy team, with ongoing testing I often find we have a production version of the site, a version under test, and another version being actively developed.

In fact it can be less clear than this if release planning isn’t a priority, some teams simply churn out releases some of which get tested and eventually released.

This can lead to developers being unsure which update hooks have actually run on production (or will have run by the time the next release goes live).

In this case it’s important for somebody to manually review all install files that have been edited and check that we don’t end up releasing update hooks that have been edited after they have been run.

This script fires up a visual diff tool for the changed files.

I’ve found the recent thread on distribution support very interesting.

An I’m especially excited by the prospects hinted at here

#42 webchick - October 7, 2010 - 21:40

For those who haven’t read it, http://buytaert.net/8-steps-for-drupal-8 is worth a read. In it, step 6 is “Backport small changes to stable releases”. Drupal 7 is the first release we’ve been able to entertain the idea, since we have a testing framework with 25K tests and a version-specific dependency system. What the boundaries are of such changes isn’t quite defined yet, because Dries and I have kept pretty busy with, you know, getting Drupal 7 out the door. :P~

Reading Greg’s post on security upgrades and a few mentions of patches in the following discussion got me thinking about upgrade methods.

The standard Drupal method is to delete existing files and unpack a tarball to replace the old version - I find this method unappealing because: I keep my code in subversion so don’t want to delete the .svn subdirectories, and sometimes I have patches applied that I don’t want to loose.