[development] CVS branch work best practices?
merlin at logrus.com
Fri Feb 2 17:16:32 UTC 2007
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
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.
More information about the development