On Fri, Oct 03, 2003 at 02:00:04AM -0400, Greg Hudson wrote:
> On Fri, 2003-10-03 at 00:50, kfogel@collab.net wrote:
> > As for 0.32, Beta, and 1.0: The plan is that once 0.32 is complete, we
> > are officially "in Beta". At that point, we will make a release
> > branch (called "stabilize-1.0" or something), which will be for
> > bugfixes only. There will be cross-pollination between trunk and the
> > 1.0 stabilization branch, but risky new features will stay confined to
> > trunk. When the branch is ready, we release 1.0, and have a party.
>
> Is it really a good idea to branch at beta? Do we really want to try to
> be stabilizing for 1.0 at the same time as we're adding features to the
> trunk? It seems wiser to just declare a tight feature freeze and have
> our whole community behind the same trunk.
That is a very good question. The concept of a stabilization branch is
based upon the premise that people are here as volunteers, and many with
conflicting goals. There are people who really want to see 1.0 produced,
and others that are more interested in what SVN can do for them [and the
1.0 label is irrelevant]. A mechanism to manage those conflicting
directions is a stabilization branch: each "sub-community" (if you will)
can work on the branch that interests them. Those who strive for 1.0 will
concentrate on the branch. Those that are uninterested will continue
working on the trunk.
Your suggestion assumes the dev community is only working towards 1.0, or
that they are willing to refrain from their own work/interests while the
other portions of the community are persuing 1.0.
Yet another possibility is that we don't actually have these envisioned
subcommunities :-)
Personally, I'm quite happy to stabilize on the trunk. My only concern is
if people will take issue with being told, "sorry. not going to apply that
patch" or "that bugfix is too risky" or "we don't want that config option"
or whatever it might be. Moving from "0.32 done. call it beta." to the
final 1.0 could mean *weeks* without a commit. The said (unsaid?) desire
is to provide "soak time" to see if bugs come in that we haven't seen yet.
And (IMO) a good soak time is measured in weeks. Get a bug report, fix it,
and then go for another couple weeks. Repeat :-)
Is the resulting "sorry, no commits" pressure (over an extended period)
sustainable by the SVN dev community? I really have no idea. With my
CollabNet hat on, I can certainly say, "sure. we have no problem with a
no-commits soak time." But we *are* a minority in this community.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 3 09:20:09 2003