On Jan 12, 2005, at 3:10 PM, Nick Patavalis wrote:
> On 2005-01-12, Ben Collins-Sussman <sussman@collab.net> wrote:
>>
>> The HACKING file in subversion's source tree describes our own release
>> process.
>>
>> Also, last weekend I documented this pattern in the svn book:
>>
>> http://svnbook.red-bean.com/en/1.1/ch04s04.html#svn-ch-4-sect-4.4
>>
>
> Thanks for the pointer. This is very interesting indeed. Some
> comments:
>
> Teams continue to work in parallel. One team begins rigorous testing
> of the release branch, while another team continues new work (say,
> for version 2.0) on /trunk. If bugs are discovered in either
> location, fixes are ported back and forth as necessary. At some
> point, however, even that process stops. The branch is "frozen" for
> final testing right before a release.
>
> [ ... ]
>
> The branch is maintained over time. While work continues on /trunk
> for version 2.0, bugfixes continue to be ported from /trunk to
> /branches/1.0. When enough bugfixes have accumulated, management may
> decide to do a 1.0.1 release
>
> I assume that during the "stabilization period", after branches/1.0 is
> created, and before the software is released, most developers work on
> the 1.0 branch, instead of on the trunk. After the first release is
> tagged (tags/1.0.0 is created) and shipped, developers switch-back
> working on the trunk.
Well, it's not an either-or thing. If you're resource constrained,
sure, I guess that could be the case. But that's the whole point of
creating a branch: so that new work can happen on the /trunk at the
*same time* that stabilization fixes are happening on the release
branch. If you're so resource constrained that people can only work in
one place or the other, then heck, just "freeze" trunk. No need to
make a branch at all. :-)
> In a trivial case, when no post-1.0.0 features
> are contemplated while getting ready for the first release (something
> thay may not be unreasonable for small development team), the 1.0
> branch and the 1.0.0 trunk are created "simultaneously".
You mean "1.0.0 tag" here, right?
> In this case
> the branch is still created (instead of copying directly from trunk to
> tags/1.0.0) only to maintain "symmetry" by validating the assertion
> that "all 1.0.x release-tags are snapshots of the 1.0 branch".
>
Sure. It's nice to keep your house in order like that.
> The second quoted paragraph seems to insinuate that once the first 1.0
> release is out (once 1.0.0 is out), no one ever works directly on
> branches/1.0 again. Only modifications from trunk are merged in it. I
> would think though that, occasionally, some work may be committed
> directly on the branch (not merged from the trunk). For example,
> fixing a serious bug that is no longer applicable to the diverged
> trunk.
In practice, that doesn't happen very often. But yes, it's definitely
plausible.
>
> The branch is maintained over time. While work continues on /trunk
> for version 2.0, bugfixes continue to be ported from /trunk to
> /branches/1.0. When enough bugfixes have accumulated, management may
> decide to do a 1.0.1 release: /branches/1.0 is copied to
> /tags/1.0.1, and the tag is packaged and released.
>
> I assume that this---as well as other similar phrases above---should
> read: "The branch is maintained over time. While work continues on
> /trunk for version *1.1*, bugfixes continue...". Otherwise I fail to
> see the purpose of the middle zero in the release numbers.
>
I was deliberately being simplistic by assuming 2.0 follows 1.0. But
yes, in most projects, 1.0 is followed by 1.1. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Jan 13 04:29:24 2005