[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