[drupal-devel] RFC: drupalversions.module

[Bèr Kessels]

Id say: just use the hook_help for this.
 case "admin/versions#mymodule" 
   return '$id$ for 4.6'

$id$ is filled from svn/cvs. 4.6 must be hand-edited on a release

But, while all this is nice, i beleive Adrian had a versioning system built in 
the update/install system. 

Op donderdag 28 juli 2005 17:45, schreef 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/
Regards,
 Bèr
-- 
 [ Bèr Kessels | Drupal services www.webschuur.com ]