On 2/1/07, C. Michael Pilato <cmpilato@collab.net> wrote:
> Ben Collins-Sussman wrote:
> > On 1/30/07, Greg Stein <gstein@lyra.org> wrote:
> >
> >> And FWIW, I am very, very strongly against any notion of 2.0.
> >> Personally, I see it as a failure in creativity. Shooting for 2.0 is a
> >> shortcut. It's a way to avoid the difficult problems. It is a way to
> >> shove development problems/maintenance at the bazillions of users that
> >> Subversion has today. Consider: 1.x clients and 2.0 servers are not
> >> compatible. 2.x clients and 1.x servers are not compatible. Each time
> >> a user wants to check something out, they will need to know the
> >> version of the server. Holy shit will that suck. Big time. Badly. One
> >> month of extra development to ensure 1.x compatibility, or a bazillion
> >> man-months of productivity loss due to a major version change. Eesh.
> >> Doesn't seem like a fair tradeoff. Hey... to be fair, it's true that
> >> I'm not personally spending that extra dev time, but I don't think
> >> that means the point is any less valid. And if/where I get to assign
> >> or volunteer time for svn dev? It'll be on 1.x. I think that the
> >> *concept* of 2.0 is just giving up.
> >
> > I agree that if we define 2.0 to mean "break all compatibility,
> > everywhere", then yes... it will be a huge PITA for users. But
> > presumably, there's some big net gain that the users get in exchange
> > for their forced-upgrade pain, no? Isn't that sort of the point.
> >
> > While I agree with your sentiment above, it also looks like an excuse
> > to never, ever, ever release 2.0. Your argument above could apply to
> > pretty much every radical feature or design-change that ever gets
> > proposed in the future, couldn't it?
> >
> > So I'm curious, Greg -- in your mind, what *would* justify a 2.0?
>
> I've always kinda thought of "2.0" as the point where we finally say two things:
>
> * we've had it with duct-taping features onto our existing repository
> backends, and so we're ready to start clean with them, sans schema
> compatibility concerns.
>
> * it's time to really drop our deprecated APIs and reset our function
> version counters (s/svn_client_commit43/svn_client_commit/).
My only problem with this definition of 2.0 is that like Greg's idea,
it's defined in terms of "what's convenient for developers" -- i.e. we
get sick of maintaining a bunch of deprecated APIs, we get sick of
trying to add new features without toppling the house of cards, etc.
What I'm trying to say: if 2.0 is going to be a huge pain for users to
upgrade to ("you must upgrade all servers AND all clients! you must
dump and reload!"), then we need to give them a really good motivation
to go through all that. We have to offer them insanely amazing new
features. Our press release for 2.0 cannot read, "Subversion 2.0:
same as svn 1.7, but um... cleaner on the inside..."
So I guess I'm sort of afraid that if we come with all sorts of clever
ways to implement groundbreaking new features in 1.X, we've
essentially tossed away a bunch of powerful ammunition we could use to
promote 2.0.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Feb 1 18:51:21 2007