On Thu, 2004-07-01 at 19:09, Ben Reser wrote:
> Greg and I had a long discussion about this on IRC yesterday (or maybe
> it was the day before that). I disagree with his argument that we have
> to go to 2.0 just because of this.
It's important to recognize two of Ben's presuppositions from the IRC
discussion:
(1) He doesn't worry about how our policies and decisions affect
binary packagers; and
(2) He doesn't find it important for binary distributions to ensure
binary compatibility between full releases; for instance, he finds it
okay that Mandrake doesn't work to ensure that an application built on
Mandrake 9 will continue to work un-upgraded under Mandrake 10.
I think these tenets are ruinous if applied across a whole operating
system. If an operating system is to have a real base of third-party
applications, it needs to at least try hard to provide binary
compatibility.
It's possible that we can get away with sacrificing backward
compatibility at this relatively early stage because we have so few
third-party applications built against Subversion. But that's the only
reason; the fact that the incompatibility comes from a downstream
dependency is irrelevant.
> Greg is arguing here that our compatibility requirements require us to
> ensure binary compatibility even if the binary incompatibility may be
> coming from a dependency. To ensure this we have to refuse to work with
> any dependency that breaks our binary compatibility.
Actually, I'd say it's enough to nail down the major versions of
dependencies *in the default build*. If someone wants to build svn 1.x
using a --with-apr1 option, that's fine; and if a distribution wants to
exercise that option because they don't care about binary compatibility,
that's sad but it's their call.
> It carries the cost of forcing everyone to upgrade to Apache 2.1/2.2
> when we do our 2.0, and forcing everyone who doesn't want to upgrade
> to our 2.0 to stay with Apache 2.0.
Well, we may be able to compromise on this point by allowing explicit
configure options to build against the non-specified dependencies.
Regardless, I'd say this pain comes from Apache, with their apparent
blithe disregard for binary compatibility in httpd. Every time you
create a new incompatible ABI version, you create pain. We can choose
to pass that pain on to our direct users in the form of more rigid
dependency requirement, or onto our third-party developers in the form
of a poorly-defined ABI.
> This is really no different than bdb 4.1 vs bdb 4.2.
This is quite different. BDB 4.1 vs BDB 4.2 has no effect on the ABI we
present to applications unless they themselves use BDB, which is rare.
(If the application still uses BDB, then it may still win depending on
how clever the linker is, I think.)
Certainly, the lack of data format compatibility between BDB versions is
one of the reasons why it was a horrible awful brutal mistake to use BDB
in Subversion. As I'm fond of saying, we built on quicksand, and we've
seen how our users have suffered as a result. But it's not really an
ABI issue for us.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 2 05:27:40 2004