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@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Bèr Kessels Sent: Friday, February 02, 2007 3:13 PM To: development@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