[development] CVS branch work best practices?

[Dries Buytaert]

On 02 Feb 2007, at 18:16, Earl Miles 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.

What Earl says is true iff you assume that you use contrib's HEAD to  
track core's HEAD.  That's not what I meant.  What I meant is that if  
you don't plan to add new features to the stable/supported version of  
your module in the DRUPAL-5 branch, you can use contrib's HEAD to  
develop against core's DRUPAL-5 and ugprade to core's CVS HEAD when  
the time is right.  Here the "time is right" could depend on various  
things -- a core patch that you depend on got committed, HEAD is  
frozen, etc, etc.

--
Dries Buytaert  ::  http://www.buytaert.net/