Re: Branching vs Tagging for release candidates

[Greg Akins]

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

On Tue, Jul 7, 2009 at 11:07 PM, Alan D.
Salewski<address@hidden> wrote:
> 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.

> 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).

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

>
>    * 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?
>
>    * 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


>
> HTH,
> -Al
>
> --
> a l a n   d.   s a l e w s k i             address@hidden
> --------------------------------------------------------------------
>                        mail order bargins
>                      self-cloning apparatus
>                       fun for whole family
> --------------------------------------------------------------------
> Generated from Haiku-O-Matic:           www.smalltime.com/haiku.html
>
>
>



-- 
Greg Akins

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