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/

This whole idea of making it easier for site administrators to identify which release and versions of core code and modules is one I've brought up several times before over the past couple of years. I have even submitted several patches against core to support the idea, and at one time even coded an XML-RPC module which would allow third-party remote support and problem reporting which would provide version info as needed. It always seemed to fall on deaf ears, so I am really happy to see some people showing interest in this idea. As a site administrator with multiple Drupal sites to manage, the things I most often want to know are: 1. What is the release version of the core that is running? 2. Which additional modules and themes are installed? 3. What are the versions of those additional modules and themes? 4. What version of the database update is the site at? 5. Have any of the source files been patched locally? (I generally try to stay away from doing this precisely because it makes management and upgrading more difficult, but sometimes it's necessary. Being able to easily identify when that has been done is really useful.) Bèr Kessels wrote:

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

Using the RCS/CVS $Id$ keyword string only works for answering the fine grain questions. It will more often be useful with contrib modules than anything else. For the rest of the code, I want the release version, which can be gotten from the $Name$ keyword string -- if a release is symbolically tagged, and then checked out explicitly with that tag (as it should be!) when building the downloadable tarballs. Every version control system I've ever seen has this idea of version keywords, so if we move to Subversion or something else, we may need to change $Id$ and $Name$ to some other keyword, but it will be a global search/replace to do so. For some of my previous efforts, see: http://drupal.org/node/20439 http://drupal.org/node/20448 http://drupal.org/node/20445 http://drupal.org/node/20444 (4 different patches for head and 4.6, core and contrib) http://drupal.org/node/15818 -- Chris Johnson

Matt Westgate wrote:

On Thursday 28 July 2005 09:59 am, eric Farris wrote:

...

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. :)

With my contributed modules I simply print out the CVS Revision tag as part of the title on the settings page.

drupal_set_title(t('TinyMCE settings (%revision)', array('%revision' => '$Revision: 1.35 $')));

I then ask for this information when users file bug reports.

While crude, it's easy for folks to find and for me to identify version incompatibilities.

Matt

I think Matt's is an elegant solution to get revision info. But that info, though useful, can be sometimes misguiding: - My sites are in my own svn repository, which I update from time to time following Drupal releases, so I have my own revision numbers - When you have a module with more than one file, that revision numbers will only increase when updating the main module file What I'd like to have is some module_info hook, that could provide all this info and more. It would admit params like - 'revision' to get cvs revision as Matt's module does - 'version' to get a manually assigned module version, that would be assigned by moudle maintainers following Drupal's main versions, like 4.6.2.10, where the first three digits would be Drupal version, and the following ones, could be form module versions/revisions -.... maybe more, for dependencies, etc...

I am aiming to introduce module / theme / style / everything metadata with the dependency patch.

Each module will be in it's own directory , and each module will have it's own module.dsc file in the format of

variable: value

For instance, system.module will be modules/system/system.module and have a modules/system/system.dsc file with : name : system version: 4.6.2 branch: 4.6 schema: 140 (or the update_X version it needs to have to run) requires : block, filter, user, watchdog

Each module implicitly requires system , and should have a branch: 4.6

(or branch: head )

Please use an established format, eg. something parse_ini_file() can understand. It is a lot easier to parse and edit in an editor having colorer support :) Goba