[development] version = "$Name$" considered harmful in .info files
drupal at dwwright.net
Sun Jun 17 09:53:25 UTC 2007
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
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 , . 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 .
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
More information about the development