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.
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 2 00:08:02 2004