Branching vs Tagging for release candidates

[Greg Akins]

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)

[Alan D. Salewski]

Post by Greg Akins
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

Hi Greg,

A few possible alternate approaches:

After creating the branch that will become the release (6.1 above), you
could apply fixes to the branch first, and then to the trunk
(separately). It's double the work for applying a fix, but eliminates
the merge concerns; you'll never merge something unintended. It also
allows for similar but unique fixes on the two branches without worrying
about conflicts, but also introduces a decent possibility of human
error. Though I mention it here, I wouldn't really adopt this approach
in real life.

You could also introduce new features on individual branches, and when a
feature is deemed stable merge it into the trunk. With this approach,
whatever has already been merged to the trunk is "stable" and
"releaseable". Minor bug fixes can be applied directly to trunk, and
when the release date comes, simply release it. With CVS, this approach
involves (IMHO) a bit too much overhead in the way of managing branches,
though; I would only adopt this approach if my team were strong users of
CVS in general and very comfortable with branching and merging, in
particular.

However, it seems that your work patterns more naturally fall into the
following scheme: you do all work on HEAD until nearing a release. At
some arbitrary point you declare the trunk "stable-ish" for release and
require any radical changes to happen on a branch (that tracks HEAD).
Bug fixes continue to be made on HEAD and automatically merged to the
branch(es). When you get to the point where the contents of HEAD are
what you want to consider a release, you tag it as such and make your
release. You then merge your radical dev branch(es) back into HEAD and
development continues on HEAD until you near the next release, at which
time you repeat the process. The key points to this approach are:

* The dev branches are made with the intent to merge them back into
HEAD (so be sure to use merge point tags liberally).

* Once the release is tagged on HEAD, a new branch starting at that
tag should be used to apply any bug fixes to that release. This
will require double application of the fixes once the release is
made -- once on the branch created at the tag point, and once to
HEAD; the details of such fixes may or may not be identical
depending on how far HEAD has evolved from the code at the point
of the release.

* If there are no major features being added as you near a release,
there will be no separate branches to merge back to the trunk; all
stable features will have already been merged to the trunk.

HTH,
-Al

[Greg Akins]

Thanks for the detailed reply. Comments/miore questions inline...

On Tue, Jul 7, 2009 at 11:07 PM, Alan D.

Post by Alan D. Salewski
However, it seems that your work patterns more naturally fall into the
following scheme: you do all work on HEAD until nearing a release. At
some arbitrary point you declare the trunk "stable-ish" for release and
require any radical changes to happen on a branch (that tracks HEAD).
Bug fixes continue to be made on HEAD and automatically merged to the
branch(es). When you get to the point where the contents of HEAD are
what you want to consider a release, you tag it as such and make your
release. You then merge your radical dev branch(es) back into HEAD and
development continues on HEAD until you near the next release, at which
time you repeat the process.

This is pretty close to what we did. The difference is that we did
radical changes on HEAD and released the branch. Part of the reason I
did this was to make myself the "sole" branch maintainer and allowing
the two other developers who don't have as much CVS knowledge to just
keep working on HEAD like they always did.

Post by Alan D. Salewski
   * The dev branches are made with the intent to merge them back into
     HEAD (so be sure to use merge point tags liberally).

I haven't heard of the term "merge point tags". Is that a specific
CVS "command" or a SCM "technique".

Post by Alan D. Salewski
   * Once the release is tagged on HEAD, a new branch starting at that
     tag should be used to apply any bug fixes to that release. This
     will require double application of the fixes once the release is
     made -- once on the branch created at the tag point, and once to
     HEAD; the details of such fixes may or may not be identical
     depending on how far HEAD has evolved from the code at the point
     of the release.

So you're saying that before the release, 6.1 is the HEAD and 6.2 is
on the branch. But after the release 6.2 continues on HEAD and 6.1 is
branched in case bug fixes are required. Is that accurate?

Post by Alan D. Salewski
   * If there are no major features being added as you near a release,
     there will be no separate branches to merge back to the trunk; all
     stable features will have already been merged to the trunk.

This we'll definitely strive for. I would like to get down to very
minor bug fixes before I do the first branch. We're small enough that
as larger fixes are required, it doesn't make much sense to have
anyone "leave" the release team to work on major features that aren't
planned for the release.

If my ASCII art works OK here, this is what I think it should look
like if I do what you're suggesting.
1. We branch when things are close to release.
2. Some next version works happens on the branch.
3. The HEAD is tagged/released and then the other changes are merged
into start work on the next release.

6.2 ____________
/ \
/ \
trunck ------------------------------------------
| |
nearing RC 6.1 Just finished 6.1 General Release

Post by Alan D. Salewski
HTH,
-Al
--
--------------------------------------------------------------------
                       mail order bargins
                     self-cloning apparatus
                      fun for whole family
--------------------------------------------------------------------
Generated from Haiku-O-Matic:           www.smalltime.com/haiku.html

[Knuplesch, Juergen]

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: info-cvs-bounces+juergen.knuplesch=***@nongnu.org [mailto:info-cvs-bounces+juergen.knuplesch=***@nongnu.org] Im Auftrag von Greg Akins
Gesendet: Dienstag, 7. Juli 2009 17:13
An: info-***@nongnu.org
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

[Paul Sander]

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.

Post by Knuplesch, Juergen
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."
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
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-----
] Im Auftrag von Greg Akins
Gesendet: Dienstag, 7. Juli 2009 17:13
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
***@wakawaka.com

[Roddie Grant]

Post by Alan D. Salewski

Post by Greg Akins
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.

<snip>

Post by Alan D. Salewski

Post by Greg Akins
Greg Akins

Hi Greg,
After creating the branch that will become the release (6.1 above), you
could apply fixes to the branch first, and then to the trunk
(separately).

<snip>

Post by Alan D. Salewski
You could also introduce new features on individual branches, and when a
feature is deemed stable merge it into the trunk.

<snip>

Post by Alan D. Salewski
However, it seems that your work patterns more naturally fall into the
following scheme: you do all work on HEAD until nearing a release. At
some arbitrary point you declare the trunk "stable-ish" for release and
require any radical changes to happen on a branch (that tracks HEAD).

<snip>

This thread has been very useful, and I'd appreciate pointers to more about
the daily handling of CVS.

My knowledge of CVS is based mainly on Essential CVS by Jennifer Vesperman;
it's a good book but rather theoretical. I'd be interested in knowing more
about how CVS is used in practice.

For instance, how do users record details of tags? And by this I mean the
nitty-gritty - is it in special software...in Excel...in a notebook...on the
back of an envelope... And what do you record?

Similarly, what sort of things is it useful to include in commit log
messages?

I realise that what other people do may not be directly relevant to me, but
it would still be useful to see examples. I'm a one-one-band web developer
using CVS to manage development, test and live versions of each site. Some
aspects of CVS make life so much simpler, but I have the feeling that I'm
not getting the most out of it.

Thanks

Roddie Grant

[Todd Denniston]

Post by Greg Akins
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)

I would like to suggest looking at what some of what Brad Appleton has
documented. It may not give exactly the answers you need, but it will probably
help you discuss what you want to do with others.

http://www.cmcrossroads.com/bradapp/acme/branching/#StreamedLines

http://www.cmcrossroads.com/bradapp/acme/branching/

http://www.cmcrossroads.com/bradapp/acme/


++ Are you trying to make a release candidate from a mainline that has all the
functionality that you want for the release, but needs QA and bug fixes.

in that case I think what might serve you well is a "Parallel
Maintenance/Development with a LAG Development Line"
http://www.cmcrossroads.com/bradapp/acme/branching/branch-structs.html#ParallelMaintDev
make the "Maintenance"/Release branch

++ Or Are you trying to make a release candidate that lets folks see condition
of the current stable state of development?

in this case I think a Docking or Staged line setup would be better
http://www.cmcrossroads.com/bradapp/acme/branching/branch-structs.html#DockingLine
http://www.cmcrossroads.com/bradapp/acme/branching/branch-structs.html#StagedLines
Though if there is more than one new feature going in, you might want to have
multiple devel_line branches, one for each feature until each feature is
stable enough to be inflicted on others.
http://www.cmcrossroads.com/bradapp/acme/branching/branch-policy.html#MYOC

[Greg Akins]

On Wed, Jul 8, 2009 at 10:25 PM, Todd

Post by Todd Denniston
I would like to suggest looking at what some of what Brad Appleton has
documented. It may not give exactly the answers you need, but it will
probably help you discuss what you want to do with others.

Thanks! I had read Brad's book a while ago, but wasn't aware of these websites.

Post by Todd Denniston
++ Are you trying to make a release candidate from a mainline that has all
the functionality that you want for the release, but needs QA and bug fixes.

I think this most accurately describes what we are trying to do.

Post by Todd Denniston
++ Or Are you trying to make a release candidate that lets folks see
condition of the current stable state of development?

However, this is an interesting idea that hadn't occurred to me. It
might allow us to get closer to a "releaseable" version without as
much churn as we wind down toward our release date. Often the reason
for the churn is that our implementation is so far off what the
business was expecting.

[Yaron Yogev]

Hello Roddie,

Post by Roddie Grant
This thread has been very useful, and I'd appreciate pointers to more about
the daily handling of CVS.

<snip>

Post by Roddie Grant
For instance, how do users record details of tags? And by this I mean the
nitty-gritty - is it in special software...in Excel...in a notebook...on the
back of an envelope... And what do you record?

In Jungo we use a CSV file to keep all the details of the branches and
tags.
The file is also committed into CVS, and upon commit we update our
MySQL database, which is later used for various uses, e.g. pre-commit
validation,
branch locking, auto-merge path calculation, and more.
We also create a special file in the CVSROOT directory, keeping the
relationships of branches and tags (e.g. "T1 is located on B1 in 12-
Jul-09 05:00 UTC"). This allows us to do soft-tags and soft-branches,
used in fast deploying of tags & branches on our huge CVS repository.
See my post regarding soft-tags:
http://groups.google.com/group/gnu.cvs.bug/browse_thread/thread/43b1c62b5d990d89/b62a6c86d8da8448?hl=en&q=cvs+soft-tags#b62a6c86d8da8448
and this patch in savannah:
http://savannah.nongnu.org/patch/?6150

some of the data in the CSV file:
- symbol: CVS name of branch/tag
- version: Bugzilla display name of branch/tag
- repository: subtree where in the CVS tree where the branch/tag may
be used
- isbranch: is this a branch ?
- onsymbol: name of CVS symbol on which this one is located.
Examples: tag-4_1_3 is located on branch-4_1.
- owner: who is responsible for work on this branch/tag
- creator: who created this branch/tag
- tag_date: when was the branch/tag created
- mergeto: (optional) for branch - name of branch into which to do
automerge
from this branch
- description: text description of branch/tag
- qa_owner: if defined, used as default Bugzilla QA contact for
bugs/enhancements on this branch
- soft_tag: is this a soft branch/tag ?
- allow_manual_tag: allow "cvs tag" operation with this branch/tag ?
(our policy is it should be 0 unless specifically authorized by IT)
- allow_commit: if 0, blocks committing on branch. Always 0 for tags.
- display_in_bugzilla: if 1, it will allow this branch/tag version
name to be
used in Bugzilla.

Post by Roddie Grant
Similarly, what sort of things is it useful to include in commit log
messages?

other than the description of the commit itself, which is well worth
another discussion, we sometimes include:
- "NOTIFY" header - tells post-commit daemon to notify specific people
of this commit
- we also have a way for people to specify that they want to be
notified on changes in specific parts/files in the repository and/or
specific branches
- "AUTOMERGE" header - tells our "review" application that this commit
should not be calculated in the line count of the review. sometimes
auto-merge can be across many branches, and we want to give the
reviewer a good estimate of how many lines of code are to be reviewed.

HTH,
--
Yaron Yogev
IT Software Developer
Jungo Software Technologies