Re: [boost] A branching/tagging idea for releases

From: Daryle Walker (darylew_at_[hidden])
Date: 2008-07-02 02:28:52

[I haven't responded because you've changed my mind and I mostly  
agree with you.  I didn't think that others will run with the ball I  
threw out there.]

On Jun 29, 2008, at 5:08 PM, Rene Rivera wrote:

> Daryle Walker wrote:
>> Here's an idea on how we can manage our source-control for releases:
>> 1.  When we're ready to start a new release, make a branch from  
>> the trunk with a name like release_1_??_x (e.g. "release_1_37_x")
>
> Why? What do we gain from having the release branch tagged with the  
> version? Why branch from trunk? And there are various drawbacks,  
> some of which where raised the last time we discussed this:
[TRUNCATE stuff I (now) agree with and/or about to reiterate]

Are you thinking about keeping the same branch name no matter which  
release (1.36 v. 1.37 v. 1.38 etc.) is being prepared?  I think  
that's what you're saying; and that plan means that testers just park  
on that branch and it'll get revised after each release cycle,  
right?  (The testers have to follow testing announcements or "cron"  
their working copy for updates.)  But isn't that branch going to be  
temporary, that we'll:

1. Tag the cut-off point on the trunk that the release will be based on
2. Make a branch named "release" based off the tag in [1]
3. Do any minimal fixes to make the branch stable
4. Tag that branch with the release number 1.??.0 and remerge to the  
trunk
(4a. This allows post-release material to still be added to trunk)
(4b. Export this new tag to create the release archives)
5. When doing a bug release, do steps [1]-[4], but base [1] off of
    the "1.??.(bug-1)" tag of the previous release of the line

So most of the time the "release" branch won't exist.  I'm not a  
subversion expert, so I wonder if the tester's working copies will  
choke during this period?  Or are we going to make the "release"  
branch shadow the trunk when we're not preparing a release, so the  
working copy isn't a dangling reference?   Note that I'm assuming  
that the trunk is generally always in a ready-to-go state, which I  
think is a good idea.

Where else would you branch from if not from the trunk?  And if you  
were going to run the release directly from the trunk instead,  
wouldn't that block people from making post-1.?? changes/additions?

[I just jumped back in, so I haven't yet gotten around to previous  
rounds of this discussion.]

 From what I've seen on this thread so far, I think we still  
wondering how bug-fix releases should be done.  Here's an idea:

1.  Once a month (or so), a release manager will pick minor problems  
to be packaged in a bug release.  All of said problems _must_ be  
listed in our Trac system.  Each issue should be as focused as  
possible.  We can list the applicable issues together under a Trac  
milestone entry for the bug release.

2.  The fixes for each issue should also be as focused as possible,  
to minimize the diff size and/or conflict-resolution pain.  I  
_highly_ recommend that applicable fixes must already have been saved  
in the trunk between releases (or nearly so), so we don't have to  
worry about the time-crunch of getting the fixes done.  (We doing one  
or two of these between each three-month regular release, remember!)   
I think Trac milestone system will help track the fixes.

3.  The temporary "release" branch will be made, this time based on  
the "release_1_??_(bug-1)" tag (instead of the trunk).  The change- 
sets from each resolved issue will be applied to the branch.  Then we  
test & touch up the branch for stability, tag it, and remerge it to  
the trunk.  (The release manager would export the new bug-fix tag to  
create the release archives.)

-- 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT hotmail DOT com