[drupal-devel] RFC: drupalversions.module

[Adrian Rossouw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I am aiming to introduce module / theme / style / everything metadata  
with the dependency patch.

Each module will be in it's own directory , and each module will have  
it's own module.dsc file in the format of

variable: value

For instance, system.module will be modules/system/system.module and
have a modules/system/system.dsc file with :
name : system
version: 4.6.2
branch: 4.6
schema: 140 (or the update_X version it needs to have to run)
requires : block, filter, user, watchdog


Each module implicitly requires system , and should have a
branch: 4.6

(or branch: head )







On 28 Jul 2005, at 7:26 AM, eric Farris wrote:

> 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/
>

- --
Adrian Rossouw
Drupal developer and Bryght Guy
http://drupal.org | http://bryght.com


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iD8DBQFC6S88gegMqdGlkasRAj6hAJ0QoJqY3Ej896SZQ5PfwwIUW4tbTwCgto5w
guOn+Lai60I4OEqnzlMVZ/o=
=7jXe
-----END PGP SIGNATURE-----