On Thu, Mar 11, 2010 at 22:44, Hyrum K. Wright
<hyrum_wright_at_mail.utexas.edu> wrote:
>...
>> 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. :)
Agreed. And yes, we will call it 2.0 because that tells our community
"there are various kinds of breakage here; read for more details".
>...
>> 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.
Hmm? I thought we are *maintaining* compat under the
org.tigris.subversion objects, and doing all the conceptual cleanup
under org.apache. Did I miss something?
> 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.)
Yes, and yes.
> 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. :)
Heh. Talk your jaw off. I designed those guidelines 10 years ago. I
think they have done a great service for our community, and I'm going
to be *very* curmudgeonly about any changes around the policy. :-)
Personally, I see no reason to leave them behind if/when we ever bump
to 2.0. Those guidelines *do* describe what a bump to 2.0 means.
Cheers,
-g
Received on 2010-03-12 07:14:06 CET