info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Branching vs Tagging for release candidates


From: Paul Sander
Subject: Re: Branching vs Tagging for release candidates
Date: Wed, 8 Jul 2009 00:34:06 -0700

Another approach is to apply your bug fixes to the release branch, then merge them to the trunk. This has the advantage that the merges will be simpler because you don't have to try to separate maintenance from new development. The risk is that the trunk may suffer regressions (due to missed merges) but if your QA department is on the ball then they should apply the bug fix test cases to the new development.

You can also use a method like submit/assemble to control the introduction of change into your release candidates. That method divorces the release candidate from the head of the relevant branch and allows the selective inclusion or exclusion of sets of related versions corresponding to bug fixes or features. It also does a kind of dependency check if there are overlaps in the source files implementing the fixes or features.

On Jul 7, 2009, at 11:49 PM, Knuplesch, Juergen wrote:


Hello,

Thanks for asking this good question I struggle myself a lot! So I know I am not alone in the univers with this challenge.

I think there is no perfect solution.
"I still havent found what Im looking for."

We use the following:
1.Every new version we release becomes a branch. (You only use HEAD) 2.The first revision of the new branch is build into a basic version of our product. 3.The developers develop happily on the branch. They comit by using a number (from our tracking system) that specifies the bug or requirement. 4.As soon as a bug or Req is finished, they mark all Resources in CVS with a "Fixlabel" 5.Then we create very often a Fix, by taking all resources that are fixlabeled into a ever increasing jar.

Creating the fix is still a tough job. (The release team are two people that have a lot of other responsibilities) The Release team has to make sure: 1.That every resource that is needed has the Fixlabel an is so included in the Fix 2.That no resource that is not finished comes into the fix (e.g. res 1 is comitted first for Bug 12 and then for Bug 10 - Bug 10 has to be released and Bug 12 not. This is a conflict the releas team has to solve) 3.So for every fix we create a list of Items that go into the fix and for every Item a list of ressources belonging to the Item. Then we check every ressource that wants to go into the Fix, if it is on the lists.
4.Make sure that the fix runs.



We achieve this by using
Eclipse CVS
A Tracking system for Bugs and requirements called CodeBeamer that has a CVS plugin so that every CVS comit is related to a number in the tracking system.
A tool that creates the lists of comits for each Trackingsystem Item


Greetings

--
J├╝rgen Knuplesch
-----Urspr├╝ngliche Nachricht-----
Von: address@hidden [mailto:address@hidden ] Im Auftrag von Greg Akins
Gesendet: Dienstag, 7. Juli 2009 17:13
An: address@hidden
Betreff: Branching vs Tagging for release candidates

I'm struggling with getting release candidates ready while still allowing my development team to work on new functionality. Doing some parallel work instead of working serially on all new features.

My concern is stability of the RC while not adding too much development overhead. Can anyone provide some advice to me?

For the version I just released, we created a Branch for the version that was going out the door (6.1). Most bug fixes were applied to HEAD and merged into the 6.1 Branch. That started to deteriorate as the HEAD got further away from the Branch. And the dev team complained that they lacked confidence that merges were getting applied correctly.

It was suggested that simply moving a tag around (re-tagging files that had been fixed in the HEAD) and building from the tag would be better. This seems reasonable. Is it? The only thing I can think of that would cause problems is if the new revision of a file can't be applied to the Tag wholesale (if the "merge" would have to be more selective to avoid incorporating new features).

Does anyone have any advice on the best way to accomplish this? Our dev team is small (me & 2 developers)


--
Greg Akins

http://www.pghcodingdojo.org
http://pittjug.dev.java.net





--
Is it "living the dream," or is it "schizophrenia"?
Paul Sander
address@hidden







reply via email to

[Prev in Thread] Current Thread [Next in Thread]