[drupal-devel] RFC: drupalversions.module

[Jeff Robbins]

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