A common request in Drupalspace is a way to keep track of which version of Drupal is running on a Drupal site. While the CHANGELOG.txt file will show the current version, that's not entirely accurate, as pieces of the code could be patched, contributed modules could be installed, or the site could be some version of Drupal HEAD (where the changelog version is moot). What is needed is a single, agreed-upon method of discovering and reporting the versions of the various code used in a Drupal installation. What I propose is a drupalversions.module to handle this task. The features of such a module should be: * discovery of the CVS $Id$ tags of every .module, .inc, .theme, .css .xtmpl, etc. storing of these version numbers * comparison of these versions to official Drupal releases, and reporting of variations from the standard release numbers reporting of all non-core files and their version numbers * a good report that could be requested by drupal-support to assist in bug tracking and problem solving. Advanced features could be: * versions of contributed modules that correspond to official Drupal core releases. For example, the author of image.module could specify that version 1.220 is the first version to be used with Drupal 4.6.0, and that it is compatible with 4.6.1 and 4.6.2, but image.module 1.224 should be used with Drupal 4.6.3, and 1.230 is for Drupal HEAD only. So the drupalversions schema would have to store the filenames of all files in the Drupal core and the version numbers of the official releases. This would have to be easily extendable/accessible by contributed modules through a hook or api. We should support problems like this (examples only): * "node.module 1.410.2.6 is the official version for Drupal 4.6.0." * "For Drupal 4.6.2, Image.module should be 1.224 or higher." * "weblink.module 1.30 requires common.inc version 1.401.2.3 or higher." * This installation is a 4.6.2 version of Drupal, except that the node.module and search.module appear to be newer, and the following contrib modules are installed..." What I'm not addressing is the question of patches. It would be simple enough, I think, to store MD5 hashes from the 'official' module and have hook_cron periodically compute the hashes and compare them with the db, which would then appear on the admin report which files weren't in sync with their official versions. How would all of this fit in to the install system? I am in no position to start contributing code to this at present, but I plan on doing so if there is such a need. I still don't know what the hook would look like or what the schema would be. So... what do you think, sirs? -- e one inch frame: http://eafarris.al.umces.edu/