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

Re: Subversion 1.5

From: Karl Fogel <kfogel_at_red-bean.com>
Date: 2007-03-08 02:06:14 CET

"Hyrum K. Wright" <hyrum_wright@mail.utexas.edu> writes:
> There are drawbacks to releasing 1.5 without merge tracking, but I think
> they aren't as big as the advantages. Of course, our users would like a
> 1.5 release with merge tracking, but I think that many of them would
> also like the other features currently in trunk, without having to wait
> for merge tracking.
> Releasing 1.5 without merge tracking would almost certainly push the
> timeline for merge tracking back, but probably not by much. The time
> spent fixing bugs for an intermediate release would also have to be
> spent on a merge tracking release. Doing an intermediate release may
> actually help to parallelize the merge tracking development and
> unrelated stabilization.
> A number of API changes would be frozen for the intermediate 1.5
> release, and those APIs may need to be rev'd to support merge tracking
> changes. I don't see this as a major drawback, though.
> What are other's thoughts about shipping 1.5 soon?

I like this plan.

And the sparse-directories support can happen in two stages anyway:

   - In 1.5, ship the new APIs, with (at a minimum) equivalent
     functionality to what we have today with -N. Ideally, we'll also
     have some of the new features described in README.branch, but we
     probably won't have all of them. Heck, some of them remain to be
     spec'd :-).

   - In 1.6, complete the feature, based on our (and our users')
     experience with the functionality shipped in 1.5.

Similar multi-stage arguments probably apply to merge-tracking itself,
but anyway, what I'm saying is, your plan works fine for sparse-dirs.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 8 02:06:48 2007

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.