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.