[development] CVS branch work best practices?

[_craig]

Since most module development is fairly linear, I'm a little surprised I
haven't seen anyone (re)mention creating version-specific tags directly in
MAIN, and branch from there only if necessary (recently discussed here
http://lists.drupal.org/archives/development/2007-01/msg00511.html).

|
|- tag DRUPAL-5--1-0
| 
|  <- adding new features, bugfixes, whatever
|
|- tag DRUPAL-5--2-0
|
|  <- update to drupal 6.x
|
|- tag DRUPAL-6--1-0
|
HEAD.

No big deal if a bug/security fix is needed for DRUPAL-5.  Just create a
branch off of DRUPAL-5--2-0 and apply it to that branch.  Yes, I realize the
downside: a select few who obtain modules via CVS may get annoyed.  But the
upside: this is easier on the module developers (at least those who know
what they are doing with CVS) and has no impact on normal users downloading
gzips from d.o. (thanks to derek's recent work on the project module).  This
method also has the added bonus of allowing CVS users to assume HEAD is the
latest and greatest.


(Fixed a bug in DRUPAL-5--2-0 AFTER drupal 6.x work has begun)
|
|- tag DRUPAL-5--1-0
| 
|  <- adding new features, bugfixes, whatever
|
|- tag DRUPAL-5--2-0  -- DRUPAL-5--2 BRANCH
|                                 |  <- fix bug
|  <- update to drupal 6.x        | - tag DRUPAL-5--2-1
|
|- tag DRUPAL-6--1-0
|
HEAD.



 

-----Original Message-----
From: development-bounces at drupal.org [mailto:development-bounces at drupal.org]
On Behalf Of Bèr Kessels
Sent: Friday, February 02, 2007 3:13 PM
To: development at drupal.org
Subject: Re: [development] CVS branch work best practices?

Hello.

I'd love too keep this whole discussion on track :) , so lets summarize: 

* Dries suggest we either go for a), or b). A) being 'you wait for
improvements until there is a new core release'. B) being, you keep HEAD in
track with core HEAD. 

* Many people suggest that there are a lot of ways to tackle module
maintainance. To me this proves that my orgininal request -to find a
good/best practice- is far from the trivial question I hoped it to be. There
*is* no best practice, there are at least four, depending on your needs and
skills, and probably more.

* People mentioned in several occasions that CVS is difficult stuff. I think
this is a known fact for many, but it is a very important fact. Dries talked
about 'keeping code accessible for new developers' often. Well, Drupal code
may be that, I think the 'required' CVS skills to actually use/contribute
the work defeat a lot of that accessible code. Just a thing to remember,
IMO. 

* While choises are good, I think my original question: what is the way to
maintain your modules without spending loads of time on CVS matters (as in: 
spend your time coding, not in CVS burocracy), has only been answered by
ajk. 
Let me stress that this is not the only one. Its just the best (IMO) if you
want to Spend Less CVS Time, and more code-quality time. This 'best
practice' 
went into the handbook already. Thanks ;)

I think the discussion in this thread proves above all that CVS is, eehm,
not perfect. But to quote Boris: it just sucks less. 

Bèr
--
Drupal, Ruby on Rails and Joomla! development: webschuur.com | Drupal
hosting: 
www.sympal.nl