[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 0.32, the "1.0" milestone, and the 1.0 release.

From: mark benedetto king <mbk_at_lowlatency.com>
Date: 2003-10-03 18:32:32 CEST

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.

One of the real strong points of svn is that branches aren't really that
different from the trunk.

I don't see a big difference between these two scenarios:

1.) a pre-1.0 (or beta, or whatever) branch, doing only bugfixes to it
    while doing potentially destabilizing work on the trunk (and merging
    the bugfixes from the branch into the trunk)


2.) a feature freeze on the trunk, doing only bugfixes to it, while
    doing potentially destabilizing work on branches (and eventually
    merging them all into the trunk after the 1.0 release).

The biggest difference that comes to mind is the revision-history blindspot
created by merging; it might be nicer in this respect to do the as much work
as possible directly on the trunk. However, we have this same problem
already for the changes that are produced on branches.

So, I'm -0 on using the trunk as the release branch, but only because
it might blur the changes made on other branches and merged in later.
If we can agree to focus only on bugfixes, then I'm +1 on using the
trunk; that way there's no merging at all.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 3 18:33:21 2003

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.