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/