[drupal-devel] RFC: drupalversions.module

[eric Farris]

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/