On Thu, Mar 11, 2010 at 22:44, Hyrum K. Wright <[email protected]> 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
