[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: <kfogel_at_collab.net>
Date: 2003-10-03 17:48:20 CEST

mark benedetto king <mbk@lowlatency.com> writes:
> 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)
>
> and
>
> 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).

Those aren't really the scenarios we're contemplating. Rather, it's a
question of

   1. Continue regular development, including new features, on trunk,
      while using a stabilization branch for 1.0? Or,

   2. Stabilize trunk, and just don't do new feature development until
      1.0 is out.

(2) has a bigger impact on developers who might want to work on new
features. It effectively asks them to forgo that work, and either sit
tight or help fix bugs instead.

> 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.

Exactly, me too.

Would any developers be very uncomfortable with (2)? It would be
great if we all felt pretty much the same way about the relative
priority of 1.0 versus new feature dev at this time... But I don't
want to presume.

---------------------------------------------------------------------
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:40:15 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.