[Joe Orton]
> Sorry, that message was rather obtuse :) My argument was supposed to be:
> current Subversion releases already implicitly and explicitly support
> APR 1.x (and hence httpd 2.2), therefore changing the SVN library
> sonames based on use of APR 1.x is an unreasonable break of backwards
> compatibility.
Thanks for clarifying.
If the status quo means, as you argue, that Subversion already
explicitly supports apr 1.x, then you have already broken the promise
or expectation of binary compatibility for libsvn_*. That being the
case, I do not see an additional evil in doing it again, assuming (as I
have argued) that there are solid technical reasons to do so.
> I think it would certainly be unreasonable for the SVN project to
> refuse to support APR 1.x/httpd 2.2 (in some abstract way) merely
> because SVN cannot be packaged to allow backwards-compat across APR
> major versions, which is something I'd presume the vast majority of
> users don't care about (witness, lack of anybody caring about it for
> the 18 months APR 1.x has been available).
I don't quite see how you can have it both ways. If the vast majority
of users don't care, why _not_ make a change which is agreed to be
technically correct but breaks a promise (which has already been
implicitly broken once)?
I think ghudson hit upon something when he noted that early adopters of
apr 1.x already accepted the need to recompile all their binaries that
use libsvn; they shouldn't mind having to do it again. Put another
way: there are two classes of people using subversion with apr 1.x:
users of early-adopter distributors like Fedora, and early-adopter
users who compile this stuff on their own. For the former, users
shouldn't even notice the change - the job of the distributor is to
make these things happen smoothly. For the latter, 'make install' will
not overwrite their old libraries (since the filenames have changed),
so their old apps will continue to work with the old library, until
they happen to recompile them.
One last point: I also dispute the 18-month figure. apr 1.x may have
been around that long, but Apache 2.2 has only been available for 4
months. I would bet that most users only migrated subversion to apr
1.x when they installed Apache 2.2. It may not change the substance of
your argument to go from 18 months to 4 months, but I think it's worth
noting. Remember, four months ago, 1.3.0 was in the middle of its long
release process (I think it was at rc5 or so). Given that the release
was already somewhat delayed, even if I had realised at the time that
this problem was worth bringing up in public, I don't think it would
have been reasonable to delay the 1.3.0 release even further over it.
Peter
Received on Fri Mar 31 13:45:05 2006