[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 20:57:25 +0100

On Thu, Feb 28, 2008 at 8:34 PM, David Waite <dwaite_at_gmail.com> wrote:
> I think its rather obvious that the subversion development model is too
> rigid.

I'm interested in hearing from you why you think that, especially
because I see nothing wrong with the model itself. I do see large
problems with how we implement our release schedule, but our API
versioning rules don't really require us to do so few releases...

> 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 :)

I do agree that it's vital to get something out to users, but I'm
wondering what it is that *you* require most. My question comes from
the following: If we had released more often in the past 2 years (that
is 1.4 > 1.5 > 1.6), we just would have released some of the other
features, but not merge tracking: it simply has been declared 'done'
only quite recently.

In other words, moving to a more pragmatic model wouldn't have served
the 'merge tracking' users more than the current model.

Taking that into account, what do *you* hope to win with a different
model? (Sincere question!)



> On Thu, Feb 28, 2008 at 10:02 AM, 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. 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
> >
> >

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:57:46 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.