[development] chasing HEAD? vs remove it? (was Re: CVS branch work best practices?)

[Derek Wright]

re: what to do with your contrib module's HEAD "branch"...

i knew this would be a big question, given the increased flexibility  
the new release system provides maintainers, so i wrote this section:

http://drupal.org/node/17570#HEAD

my stance on this debate changed a lot in the course of the 5.x core  
development cycle.  i used to agree whole-heartedly with earl:  
chasing HEAD is a bad idea unless you really know what you're doing.   
now, i mostly agree with moshe: chasing HEAD is great if you're up  
for it.

there were a handful of (at least to me) fairly serious bugs in the  
5.x API that i only noticed once i tried to port project* to it.   
it's a small miracle that we managed to get all of the core patches  
to fix them accepted, even though it was after the code freeze  
(thanks Dries, Unconed, et al!).  no blame goes to any of the folks  
who contributed these otherwise great improvements to core (whomever  
they were) for not handling these edge cases that project* was  
hitting... it was my responsibility as the project* maintainer to  
notice and sound the alarm, not the folks for whom the core patch  
worked in all the testing they could dream up with sane (ahem)  
modules. ;)

bottom line on this point: if you're up to the task, trying to keep  
your module's version of HEAD in sync with the (ever-changing)  
version of the API in core's HEAD is a worthy, noble goal, and it  
should be encouraged as much as possible.  if they keep up with the  
changes, contrib developers:

a) will be more familiar with the new changes to the API taking  
place, and in general, be more knowledgeable about the core API itself

b) will have more chances to find/correct problems with the API  
changes while there's still room to move

c) won't have to do all the porting at once

d) will help add momentum to the new version of core, since as soon  
as the first RC ships, there will already be a set of modules  
compatible with it

...

of course, all of this requires more work, and certainly not every  
contrib maintainer is up for it.  a lot of what earl says is still  
absolutely true.  but, moshe is fundamentally right on this: there's  
no need to actively discourage people from doing this work if they're  
willing and able.

cheers,
-derek

p.s. i've got to think about this "just remove all the files from  
HEAD except a README.txt" approach before i strongly stake a  
position.  part of me recoils in shock, since that's not how You're  
Supposed to Use CVS(tm).  however, part of my loves it, since i  
positively HATE the problems that come when people try to use HEAD  
"releases" for real sites...

however, i think the impetus for adding this "3rd way" came from not  
really understanding the simplicity of the first scenario i laid out  
in the handbook page linked above.  it seems the remove-all-the-files  
scenario creates a handful of problems (some minor, some major) and  
additional work that should be hashed out before a) anyone actively  
goes down this route and b) this remains as a recommended approach in  
our CVS handbook.  unless there's strong opposition, i'd like to  
revert the latest revision to the page, at least until we've clearly  
decided it's another approach worth advocating for in some  
circumstances.  right now, i'm leaning towards saying this is a bad  
idea, and people shouldn't be doing this to their contribs.