On Mar 11, 2010, at 3:57 PM, Greg Stein wrote:
> On Thu, Mar 11, 2010 at 11:18, Hyrum K. Wright
> <hyrum_wright_at_mail.utexas.edu> wrote:
>> On Mar 11, 2010, at 9:31 AM, Mark Phippard wrote:
>>> On Thu, Mar 11, 2010 at 10:25 AM, Hyrum K. Wright
>>> <hyrum_wright_at_mail.utexas.edu> wrote:
>>>> My general thoughts on stuff like this is that folks want a newer version of Subversion, they may > need to upgrade their dependencies. If they are unable or unwilling to do so, then they will just
>>>> have to stick with the older version of Subversion. If these means that somebody on a RHEL 4.0
>>>> box who is stuck using httpd 2.0.x can't run Subversion 1.7 without more work, tough. I suspect
>>>> these folks are a relatively small number of our usership.
>>>
>>> I don't get this. We are willing to do things like require Python 2.4
>>> (which we did in 1.6) and consider requiring APR 1.3. These sorts of
>>> things impact a significant number of our users and really bring us as
>>> developers only modest benefits in terms of making our lives easier.
>>
>> I dunno. The *vast* majority of people get a prepackaged client. As Peter mentioned elsewhere, Debian has been shipping apr 1.2.x with Subversion for some time, and I suspect that a large number of other clients have already moved to apr 1.x. The *only* people an apr version bump affects are developers and people who build Subversion from source, who are vastly in the minority. (I'd be interested to know who in the dev community still uses apr 0.9.x, for instance.)
>
> Our longstanding policy has been "hey, feel free to upgrade svn at any
> time. going from 1.x to a later version will never cause a problem."
> We chose this policy so that an admin would KNOW that nothing on the
> system would break if he updated the packages. No tools. No GUI
> clients. No repositories. No working copies. No nothing.
>
> The thing about a prepackaged client is a red herring. By removing
> compat for 0.9.x, then httpd 2.0.x users will be shut out of 1.7 and
> later. Completely. There will never be source or binaries that work in
> that environment.
To be fair, 1.7 clients would still be able to interoperate with httpd 2.0.x servers, but I understand your point.
> Strawman answer? Just don't provide packages for Apache; just the
> client. Okay, great. The admin updates the client packages, which
> includes libsvn_subr-1.so, which NOW links against libapr-1.so. The
> 2.0 httpd on that box gets restarted at some point, and loads
> libapr-0.so, and then loads libsvn_subr-1.so which loads libapr-1.so.
> OOPS. Or maybe that subr tries to work against libapr-0, finding the
> symbols already in the address space.
>
> Net result: admins no longer have a "safe update" policy. I think that
> is a big mistake.
While I agree that this has been, and will continue to be a good policy, someday we will create a release which breaks it. We can call it 2.0, but one day it's gonna happen. :)
>>> Yet, we force ourselves to jump through hoops keeping our libsvn_wc
>>> API compatible, probably tripling the amount of time it takes to
>>> rewrite it. When the impact on our users if we just said screw it and
>>> broke the compatibility would probably be minimal. After all, the API
>>> sucks how many people wrote custom tools to this level of the API as
>>> opposed to libsvn_client? And most of those users would probably live
>>> with the notion that at least their own code would get easier when
>>> they had to update it for a new library.
>>>
>>> Anyway, I know we are not going to change this approach, I just think
>>> we are our own worst enemy some times.
>>
>> I *think* what you're saying is that our compatibility guidelines are a bit screwy. If that's your assertion, I tend to agree. :)
>
> No. He's saying if you're willing throw out one measure of
> compatibility, why not the one causing us so much pain right now? (the
> wc API)
>
>> When we talk about backward compat, there are actually several dimensions we've lumped into one:
>> * API compatibility
>> * ABI compatibility
>> * on-the-wire protocol compatibility
>> * persistent storage formats (wc metadata and repos formats)
>> * command line output (for scripting purposes, etc.)
>>
>> For a long time, we've tried very hard to keep *all* of these backward compatible, but experience has shown that most users only care about a subset of these dimensions (though that subset may differ between groups of users). As Subversion continues to evolve, we need to figure out which areas are important, and which we can drop if/when we go to 2.0.
>>
>> For instance, I believe that we should maintain wire protocol compat ad infinitum, even through 2.0, simply because it allows people to continue deploy a heterogeneous client/server environment. We've already practically broken our wc metadata format, and we've occasionally extended the command line output when it's made sense. (I often wonder how people who scripted against 'svn up' dealt with the new conflict summary.)
>>
>> Staying backward ABI compatible *forever* just isn't scalable. At some point, the costs outweigh the benefits , and I'm suggesting that maybe we should start thinking about what the costs are, and whether it makes sense to tell the 0.0001% of people who'd need to recompile to do so. (This is somewhat analogous to the decision to not upgrade pending logs in wc-ng.)
>
> I believe the above statements about our compatibility guidelines are
> orthogonal to supporting APR 0.9.x. It's a fair discussion to have,
> but I believe it is a very separate and long discussion. I think if we
> want to break any level of compat, then we move to 2.0, strip the
> cruft, and restart with the *same* compat restrictions. If the step to
> 2.0 is simply dropping deprecated stuff, then most users won't have a
> problem with it; only tools using our API/ABI will need to perform
> some work. Not sure what other changes would cause a step to 2.0,
> beyond a simple desire to "rm libsvn_*/deprecated.c"
I don't know that there will be some landmark event. At some point, the cost of carrying around the backward compat gets overly burdensome, and it just makes sense to loosen the restrictions, bump to 2.0, and clean everything up. Witness the amount of cleanup that has been doable in the JavaHL bindings since we repackaged and effectively gained the chance to break API compat. Such a change can be accomplished with grace (see Python 3), and is as much a communication problem as a technical one.
As for APR, if we're not going to update the deps now, I say we don't even worry about doing it until apr 2.0 ships, and then update for that platform instead. (And as far as I know, that's still a long ways out.)
Regarding the discussion about our compatibility guidelines, that might be a good point to add to the agenda for the NYC discussions in a couple of weeks. :)
-Hyrum
Received on 2010-03-12 04:45:13 CET