[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, Technology Preview"

From: David Waite <dwaite_at_gmail.com>
Date: Thu, 28 Feb 2008 12:34:16 -0700

I think its rather obvious that the subversion development model is too
rigid. I believe moving to a development tree that is allowed to break
compatibility for several 'development' releases would be a good, however it
would be important not to move too far in the other direction and lose
pragmatism, and become an endless project.

Hopefully the delays and difficulties in 1.5 show that when functionality is
done, it needs to be given to users ASAP, in a sense making the project more
pragmatic :)

-David Waite

On Thu, Feb 28, 2008 at 10:02 AM, Justin Erenkrantz <justin_at_erenkrantz.com>

> On Thu, Feb 28, 2008 at 6:40 AM, C. Michael Pilato <cmpilato_at_collab.net>
> wrote:
> > Maybe it's time to rethink the model. Maybe we should get 1.5 out the
> door,
> > roll 1.6 with tree conflicts detection and Kamesh's merge algorithm
> > improvements and whatever other mostly-done things can be finalized and
> > delivered in under 6 months, and then seriously take on the challenge
> of
> > Subversion 2.0.
> While I'm behind doing a quick 1.6 follow-on to 1.5 if that's what's
> needed, but I shudder at yet another drawn-out release cycle. If we
> go down that 2.0 route, I'd want us to quickly churn out 2.x releases
> rather then re-entering the never-never-land that 1.5's been in.
> I do disagree with epg and mostly agree with C-Mike though on the
> broader issue. A lot of the complaints that epg raised don't warrant
> to me that we release 1.5 as a 'tech preview' but instead that we keep
> improving what we have. I *hate* *hate* the idea of not doing more
> releases more frequently and think we've shot ourselves in the foot
> with that. A lot of the complaints that were raised could have been
> resolved if we had gotten our code out quicker to test rather then
> letting it sit in trunk for years waiting for anyone other than the
> original contributors giving feedback to the changes. The best way to
> get the code improved is to do releases and get feedback on it. We
> have never said that our releases are perfect - hence I think
> 'technology preview' is more of the same ultra-conservatism and
> paralysis that has struck us lately.
> For the issues that epg raised that I personally contributed to, I'm
> happy to fix bugs on 'em, but without any other user, as long as it
> works for me, I'm not likely to tweak it. =) -- justin
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-28 20:35:04 CET

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.