[development] version = "$Name$" considered harmful in .info files

[Derek Wright]

On Jun 16, 2007, at 8:24 PM, adrian rossouw wrote:

> Is there any reason why this should not be in core?

many.  to quote http://drupal.org/node/150316 (the issue i linked to  
in the original email in this thread, about the origin of this module):

"see http://drupal.org/node/87298#comment-154604 (comment #5) for  
some some of my earlier thoughts on this problem.  see also my meta  
comments at http://buytaert.net/linus-torvalds-on-git "

since people rarely read what i link to, i'll give you the 1 sentence  
summary:

the moment we commit CVS-specific code to core, we totally tie our  
hands a) for exactly how we're using CVS and b) that we will always  
use CVS for the life of that version of core.

> Why should we require to ship with another module to clean up an  
> issue that core itself has.

core doesn't have this problem at all.

we already are responsible enough with core releases to maintain the  
"VERSION" php constant.  so, *JUST FOR CORE*, we commit the following  
to the .info files in CVS:

version = VERSION

so, if you deploy core from CVS, you already get human-readable  
version strings on the modules page.  try it right now.  checkout the  
end of the DRUPAL-5 branch on a test site, and you'll see "5.2 dev"  
for the version for all of your core modules.

CONTRIB SHOULD NOT DO THIS!  Contrib doesn't have the same version  
numbering scheme (since life is more complicated in contrib-land), so  
contrib authors that blindly copy core's .info files are doing it  
wrong, as repeatedly explained in the d.o handbook [1], [2].  as i've  
said before, given the shoddy state of contrib, it's unreasonable to  
expect that the maintainers will remember to always keep the version  
information accurate in the .info files checked into CVS, so we need  
automated tools so that contrib maintainers don't have to worry about  
this.  that's why i'm in favor of removing *ALL* version definitions  
from all .info files in CVS for all of contrib.  core's .info files  
*SHOULD* keep the "version = VERSION" checked into CVS, precisely so  
that core doesn't have this problem on its own.

> The issue I have is that we are currently using standard drupal  
> install profiles for the hosted sites, and having to ship with this  
> module extra would make the hosted install profiles a special case  
> (enabling the module above everything else).

cvs_deploy.module does nothing if you're not deploying from CVS.  it  
doesn't assume all or nothing (maybe most of your modules are  
downloaded from official releases, but you ended up checking out a  
few things you wanted to try out via CVS or something).  so, there's  
really no harm in enabling it on non-CVS sites, if that happened to  
make your life easier.  that said, i don't actually understand the  
problem you're talking about here.  i don't see why you'd have to  
"enable [cvs_deploy.module] above everything else".  you just mean  
that cvs_deploy doesn't live in any of the existing install  
profiles?  take that up with the install profile maintainers if you  
wish.  also, keep in mind this module is ONLY about a) cosmetic stuff  
and b) making update_status work correctly with sites deployed from CVS.

that said, maybe we need a notion of nested install profiles, or at  
least profiles that can be installed in serial, so that someone could  
just setup a "CVS deploy" profile that also enables cvs_deploy,  
update_status, and hopefully soon includes the handy CLI script [3].   
then, you could always install this one, then optionally install  
whatever other profile you care about.  this could potentially be  
helpful for the install_profile_API stuff that boris was working on...

> Is this going to be part of Drupal 6 at least?

no.  it's a separate module precisely because i do NOT want CVS- 
specific code in core, exactly as i mentioned in the original post in  
this thread.  you should have followed moshe's advice and read the  
issues i linked to. ;)  update_status belongs in core, cvs_deploy  
does not.

-derek

[1] http://drupal.org/handbook/version-info
[2] http://drupal.org/node/101009
[3] http://drupal.org/node/124661