[drupal-devel] RFC: drupalversions.module
eafarris at gmail.com
Thu Jul 28 14:59:24 UTC 2005
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. :)
one inch frame: http://eafarris.al.umces.edu/
More information about the drupal-devel