[drupal-devel] RFC: drupalversions.module

[eric Farris]

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/