[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: Erik Huelsmann <ehuels_at_gmail.com>
Date: Thu, 28 Feb 2008 19:42:38 +0100

On Thu, Feb 28, 2008 at 6:02 PM, Justin Erenkrantz
<justin_at_erenkrantz.com> wrote:
> 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.

+1! I've argued that for a *long* time (even before 1.4!). I *really*
*really* believe we should have stuck to the way we did 1.1: after a
certain number of months we looked back, saw there was a lot new
functionality and we decided that was enough to warrent a release. If
it'd been up to me, we'd have released 1.5 with some SoC projects,
some rewrites and the WebDAV proxy, which a lot of users are waiting
for (not all of which are also waiting for merge tracking)...

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

I think we should sit on the consequences of delaying 1.5 as long as
we did and release the code as a full fledged release, just as we did
with earlier releases. I'm sorry, but I'm very much against what's
happening here: first you don't want to release early, now you don't
want to call it a release. I'm having a hard time agreeing with that.
(Note that some of that may stem from the fact I already had a hard
time accepting we were not releasing redefining 1.5.)

> 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

Bye,

Erik.

---------------------------------------------------------------------
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 19:42:49 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.