On Mar 12, 2010, at 12:13 AM, Greg Stein wrote:
> On Thu, Mar 11, 2010 at 22:44, Hyrum K. Wright
> <hyrum_wright_at_mail.utexas.edu> wrote:
>
>> ...
>>> 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?
We are maintaining compat with the org.tigris namespace. The benefit, though, is that the org.apache namespace is completely new, so in those packages we can drop all the deprecated classes/interfaces/methods.
>> 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.
I do not doubt your curmudgeonliness, but I'm not talking about revamping the guidelines. Really, I think it would be useful to talk about the application thereof, not changing the policy.
-Hyrum
Received on 2010-03-12 16:27:41 CET