[development] Is DRUPAL-5 branch necessary for module?

[Derek Wright]

On Jan 22, 2007, at 7:56 PM, _craig wrote:

> Do I really need to have a separate DRUPAL-5 branch for my  
> contributed module?

i'm torn on this question, for a host of reasons:

pros for making the DRUPAL-5 branch early:

a) we have documented, expected conventions and practices to follow,  
and being consistent is good.  consistency with core is also good.

b) if they don't create a DRUPAL-5 branch *before* they start adding  
new features, people who don't really understand or have real  
experience with branch management (98% of the people reading this  
message, it seems) are more likely to screw things up and get in a  
situation where if there's a security problem in an older release,  
they have no way to release a new version that only fixes the bugs,  
and doesn't introduce new features which might break live sites.

c) people looking at Drupal via CVS will know what's going on.   
otherwise, they're stuck with HEAD, which could be anything, and  
they'd have to go look at the project node (and read through  
everything on the "All releases" page) to figure out what's really  
going on in HEAD.


cons for making the DRUPAL-5 branch early:

a) it will generate more work, since you have another branch to  
commit fixes to.  i won't pass judgement on how much more work, since  
It Depends(tm).

b) so long as you tagged your DRUPAL-5--1-0 stable release (on HEAD),  
you could delay creating a DRUPAL-5 branch until you actually needed  
it (e.g. security problem or bugs you need to fix) while still  
developing new features directly in HEAD [1].

c) the straight-from-CVS crowd is a minority and can probably be  
expected to know more than nothing.  making more work for the  
maintainers to make life easier for the people just browsing via CVS  
is not a clear win IMHO.  so long as everything is reasonable and  
sane with official releases on the module browsing pages and the  
project node, i'm a little less concerned about how things look in  
viewcvs.


so, there are good reasons for doing it both ways.  however, all of  
the good reasons for delaying the branch assume a *very* clueful  
maintainer who is careful about not screwing themselves (really,  
their users) badly in case they need to release a security update...


bottom line: i'm getting incredibly burnt out being everyone's free  
revision control consultant/tutor (and no, craig, that's not directed  
at you, or anyone in particular, so no one should take this  
personally).  if i had faith that people would read, understand, and  
correctly follow the instructions and conventions for handling  
various situations, i'd be able to suggest using some more advanced  
approaches to revision management to solve many of these problems.   
but, every time i try to unlock another door to people's revision  
control understanding, i get buried in a new avalanche of email/ 
issues/IRC questions about it.  i've been trying to build tools for  
and document/teach practices that will tend to have people get things  
right, but i can't single-handedly train the entire drupal community  
on everything about branches, release management, development  
snapshots vs. official releases, why you can't commit changes to a  
tag, etc.

therefore, if you're a power CVS user, and you know exactly what  
you're doing, and you promise never to ask me to bail you out when  
you screw something up, do whatever you think is best.  if *any* of  
those conditions are *not* met, do what i wrote in the handbooks  
(make the branch as soon as your 5.x code is stable and you're ready  
for a 5.x-1.0 release).

thanks,
-derek

[1] if you don't already know how to do this, don't try it, and don't  
bother asking.  if i wrote a handbook page about it, people would  
expect me to provide unlimited support for it.  that's the same  
reason i refuse to write a handbook page about merging branches.  if  
you can figure it out on your own, you don't need my help.  if you  
can't, i'm not going to hand you a loaded gun and say "good luck, try  
not to hurt anyone", especially given the apparently high failure  
rate of people reading and understanding the CVS docs i've already  
written.

p.s. if anyone dares to suggest that "SVN would be easier", i'll find  
a way to have your legs broken.  NONE of these problems have ANYTHING  
to do with CVS vs. SVN tool syntax.  it's all about people not  
understanding fundamental concepts of revision control and release  
management, which is totally independent of the tool we happen to be  
using.  you've been warned...