Ben Collins-Sussman <sussman@collab.net> writes:
> > Basically, I'm in favor of the procedure outlined in HACKING.
>
> Which is what? HACKING just says '4 weeks of freeze'. It doesn't say
> *where* that 4 weeks of freeze happens. :-) The question on the
> table is: should the freeze happen on trunk, or on a branch?
>
> I guess ghudson points out that it can be a combination of
> places. Freez trunk for a while, then branch, and freeze that for
> whatever's left of the 4 weeks.
It doesn't say it, but it implies it pretty clearly.
Unless you seriously intend to have *no* code changes on trunk (except
doc string or error message tweaks) for four weeks, which I don't
believe you do, then freeze means a branch.
We could freeze trunk for a little while, as you point out, and then
move the freeze to a branch, but I don't see much point in doing that.
Why not just start on the branch, and not inconvenience trunk at all?
As I wrote before: "It'd be a shame to dampen the amazing amount of
activity going on on trunk -- but it'd also be a mistake to have that
kind of change rate on a line intended for release in the immediate
future."
The benefit of a freeze can happen anywhere. The inconvenience of a
freeze only happens if you freeze trunk. Ergo, don't freeze trunk :-).
Remember, once we've branched, we're saying "This is it, unless we
find a bug so severe that we can't ship." In which case, we fix the
bug and port the change to the branch, and restart the freeze. IOW,
code ports to the branch should be very few. And doc ports are easy.
So we shouldn't think "Oh, it's a branch, which means tracking
changes, which means inconvenience." Release branches are different
from development branches -- the whole point of a release branch is to
not track most changes, and happily, this fact greatly reduces the
overhead of having the branch at all.
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 7 17:31:16 2004