[development] CVS branch work best practices?

[Earl Miles]

Dries Buytaert wrote:
>  a. For people that are OK with following core's release schedule,  it 
> is easier to develop in the CVS trunk/HEAD.  This means you can't  
> release a significant upgrade of your module until the DRUPAL-6  branch 
> is available.  In this case, your work is targeted to be  released when 
> Drupal 6 becomes available.  The Drupal 5 version of  your module is in 
> maintenance mode, just like core's DRUPAL-5 branch.

Please notes that for most contrib projects, a) is very difficult. Because 
contrib development is very much dependent upon core being stable, developing 
for Drupal 6 before code freeze is basically a Bad Idea.

1) Your target audience is very very small. Comparatively, only a handfull of 
developers will be using HEAD, and they'll be developing with it, not using 
contrib modules.

2) You will be unable to offer the people who do use your modules and are 
likely to demand features those features. Yes, you can say you've built 
them...and now they must wait until Drupal 6 is available and usable. Remember, 
the people who actually *use* Drupal (i.e, for real production purposes) are 
strongly encouraged not to use a version of Drupal until it is ready and 
stable. At our current plan, with a Jun 1 code freeze, chances are Drupal 6 
will be out sometime in the fall. That means anyone doing new features for 
modules exclusively in HEAD *right now* will experience greater than half a 
year lag of those features being available to those features being actively used.

3) Before code freeze, HEAD API changes a lot. At any given time, your module 
may simply not be functional. Sometimes commits get reverted, or go through a 
long transformation process. This is a necessary part of the development cycle. 
Contrib modules simply can't follow this. During this period I could 
theoretically spend more time keeping my module working than I spend actually 
writing new features for it. In my opinion, this is not an effective use of a 
contrib developer's time.

4) Drupal's release schedule does not match people's upgrade schedules. People 
are not able to run out and update right away; in part because 3) keeps module 
developers from updating their modules until the Release Candidate phase, when 
they're fairly confident that their work won't be broken by some important fix 
to the core. This is, perhaps, a leftover of the form API work in 4.7, where 
there was an extremely long period of change in Drupal core that was needed to 
work out all the kinks in the system, but left contrib developers rather 
frustrated. It also left actual site users frustrated because there was a long 
period where a lot of contrib development work was going on in an area that 
simply didn't have a stable codebase, so it could only be used by people 
running bleeding edge stuff -- meaning they probably didn't have production 
sites, or if they were production they were very small sites that could accept 
a big downtime when some important change had a ripple effect.

As a primarily contrib developer, Dries' solution b) is the only one that is 
truly viable if the contrib in question has a need for growth:

> b. People that want to do more than just maintain bugfix releases  of their
> Drupal 5 module will have to develop in the DRUPAL-5  branch.  This means
> you can release a significant upgrade of your  module, and maintain
> compatibility with Drupal 5.  It also means more  work/pressure as you might
> be responsible for multiple versions of  your module.