On Thu, Jul 01, 2004 at 06:07:11PM -0400, Greg Hudson wrote:
> So, two little factoids I confirmed recently:
>
> * APR 1.0 changed the default size of apr_off_t on most 32-bit
> platforms, in order to turn on largefile support by default. This
> is neat, but it means we have to think of APR 0.9 -> 1.0 as a
> major version increment, not just a stabilization.
>
> * httpd does *not* follow the APR compatibility rules. httpd 2.2
> will not provide binary backwards-compatibility with httpd 2.0.
> So, although they're not calling it httpd 3, for practical
> purposes httpd 2.2 should also be thought of as effectively a
> major version increment. In particular, httpd 2.2 will be using
> APR 1.0.
>
> According to our own rules, we cannot start using APR 1.0 during the
> lifetime of svn 1.x. But we'll have to use APR 1.0 when we use httpd
> 2.2. So, depending on when we expect httpd 2.2, we may wind up going
> straight from 1.1 to 2.0.
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.
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.
This by extension means that a given release of subversion can only work
with one set of binary compatible dependencies. We are locked into a
given set of dependencies. Subversion 1.1.0 wouldn't require APR 0.9.5
or newer, but would require APR 0.9.5 up to but not including APR 1.0.0
and would refuse to work with APR 1.0.0 or newer.
I think this would be an okay approach if we lived an an ideal world.
But it is not an ideal world. 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.
We already have plenty of people who complain about the fact that we
don't support Apache 1.3. As far as I'm concerned this would be
devastating to our ability to get people to deploy Subversion. "You
mean to get this new feature I need I have to upgrade to Apache 2.2?
What does Apache 2.2 have to do with locking?" People just aren't going
to go for it.
But even further we are source level compatible with APR 1.0 and Apache
2.1 already. chipig on IRC says he's been building and using Subversion
against the development versions for some time. We don't have to make
any code changes to support them. So Greg would be implementing an
entirely arbitrary restriction that has no real requirement.
This is really no different than bdb 4.1 vs bdb 4.2. They are not
binary compatible. You have to be linked against the right one.
However, we don't demand bdb 4.2, we work just fine with 4.1 (though
there may be some bugs that result from using 4.1, but we leave it up to
people to decide if that's a problem for them or not).
I see the following scenarios playing out:
a) Server operators, that use mod_dav_svn, if they upgrade to Apache
2.1/2.2 are going to have to rebuild subversion anyway along with every
other Apache module they have. They're not likely to do this lightly.
Many people still haven't switched from Apache 1.3 because of the module
incompatibilities (although that required source code changes which made
it a little bigger task).
b) Client only users, or users that don't use mod_dav_svn aren't
probably likely to upgrade APR.
Ultimately, I think this issue will be something people run into on an
even less frequent basis than the Apache linked against bdb 4.1 while
we're linked against bdb 4.2. Which is also relatively rare.
I think part of the reason Greg thinks we need to bump our major to
support APR 1.0 and Apache 2.2 is that every application or library that
uses our libs is by necessity must use APR. But it is just as possible
to use one of our dependencies directly as Apache/APR-Util do with bdb.
So I don't see why we have to treat them differently.
I have just always assumed (partly on the basis of the bdb handling)
that in order to have binary compatibility that it was up to the user
and/or packager, to ensure that all of the linked software that is built
that uses the same libs uses the same major versions of those libs. I
don't think this is an unreasonable expectation.
I think the appropriate response to this issue is as follows:
a) Update our compatibility guarantees to make it explicit that you
can't go building our libs with say APR 0.9 and a client with APR 1.0,
that libraries that our libs and clients link to have to be the same
major. This is already something we tell people with regularity with
bdb.
b) Do something, at build time, to mitigate the harm. Possibly a
warning to the user if they try to build with APR 1.0 that this will
break binary compatibility with existing client programs built with APR
0.9. Perhaps refusing to build against APR 1.0/Apache 2.1/2.2 unless
the user passes a configure flag saying they know what they're doing.
But whatever we do, making arbitrary restrictions on the versions that
we'll work against, even though we are source compatible is just wrong.
Ultimately, people will just patch around these restrictions anyway.
> As I've noted in the past, when we do a 2.0 release, we'll want a way
> to co-locate svn 1.x and svn 2.x so that code built against svn 1 can
> continue to function. To facilitate this, I think we want a Makefile
> target which installs headers and libraries, but not command-line
> utilities or locale files (should we have a major version attached to
> our local name for this reason?), so that one can build an svn 1
> package which won't conflict with svn 2.
>
> Also, just because we're going to 2.0 doesn't mean we need to make the
> transition any more painful than necessary for our users. We know
> there are necessarily going to be some ABI/API issues, so we should do
> all the API cleanups we have queued up, but we shouldn't take the
> early need for a 2.x as an excuse to make incompatible schema or
> working copy changes.
Agreed. I just don't think we're going to need to do 2.0 as soon as you
thing.
--
Ben Reser <ben@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 2 01:10:23 2004