Well if you're thinking about adding a hook ( hook_version()?? ) anyways, why not just use that info for this? Developers could stick the $id$ tag in there if they want, or they could choose to update it manually... or both... I propose that hook_version() would return a keyed array with several defined keys, such as: 'version', 'cvsversion' ($id$), 'created', 'last updated', 'author', 'maintainers', 'contact', 'copyright', 'description', 'homepage', 'readme', 'install', 'dbfiles' (might tell installer what to install), as well as an array of 'supported systems' containing the Drupal versions for which the module is presumably compatible. Maybe this is getting out of the 'version' scope... So maybe we're looking at hook_description() or hook_info() or something along those lines. In an ideal world, some of this information would be available to the admin/modules page as well as the projects.module for display at Drupal.org. Also, I believe that patched modules are the responsibility of the site administrator. I could understand a simple checksum-type comparison, but I don't think that we should be bending over backwards to support the chaotic world of patched and modified (a.k.a. hacked) modules. -Jeff Robbins On Jul 28, 2005, at 7:59 AM, eric Farris wrote:
On 7/28/05, Morbus Iff <morbus@disobey.com> wrote:
While I think it's a good idea, I'm not sure:
* discovery of the CVS $Id$ tags of every .module, .inc, .theme, .css .xtmpl, etc. storing of these version numbers
this is a good way to implement. Somewhere in the CVS docs, they caution AGAINST using $Id$ as a version number. Off the top of my head, I can think of some reasons why:
* CVS server crashes, wiping out all histories. Revisions start over.
* Just because I patch my local copy doesn't mean I committed my patch to a server somewhere, or that I changed the $Id$ of my local copy. Comparisions would fail.
* $Id$ isn't everywhere, is it? Does it always lock us into CVS forever, or are there easy equivalents in SVN? And, if we did switch to another RCS in the future, what happens to all the $Id$s we've been basing comparisons on?
Excellent points, all, but is there a solution that is simple, elegant, and right?
Patching your version isn't addressed by the discovery and storage of $Id$ tags, but if the MD5 hashes could be used, we would know, for instance, that even though your search.module says it's version 1.130, the hashes don't match. (it could even run a diff, would't *that* be helpful for support)
$Id$ might not be everywhere, but at least SVN has a similar construct.
So, if $Id$ isn't ideal (and I'll concede that point), are hashes the answer? something else? I'm completely open to all ideas here. I'm convinced there's a need for some sort of standardized method of providing release version information, and I'd love to see that, umm, hashed out. :)
-- e
one inch frame: http://eafarris.al.umces.edu/