Boost logo

Boost :

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
(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

Boost list run by bdawes at, gregod at, cpdaniel at, john at