apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Showstopper ... was: Tagged the tree
Date Thu, 09 Jan 2003 20:26:50 GMT
We are waiting on only one thing for APR 1.0, the full set of versioning
API functions.  I don't know where this stands, and I know Greg was
full of ideas/designs.  I'd like to see some feedback on this.

>That can't work.  httpd 2.0 needs the ability to work against a stable release of APR.
 Hence, the APR 1.0 vs. 2.0 breakout.

You are assuming that httpd 2.0 will be as long-lived a version as httpd 1.3,
but that isn't going to happen.

httpd 1.3 must be a long-lived version, because of the major overhaul involved
in creating httpd 2.0.  httpd 2.2 should be a rapidly adopted version because
deployed servers and 3rd party modules won't be nearly as hard to migrate 
as the 1.3 to 2.0 migration.  Some oddball platforms still can't build httpd-2.0 
while they can build 1.3, with the introduction of libtool.  And their favorite
modules still might not have an httpd-2.0 port, partly due to the 'moving target'
of httpd-2.0 development.

Yes, httpd-2.0 is/will be forever keyed to 0.9.  We need to clear out all of
the early design cruft going forward.  Quickly, so that authors adopting the
httpd-2.1 model have the right declarations and none of the historic and now
dead macros or stubs.  Because 0.9, for a while, will inherit the renaming
going on for 1.0, any 1.0 code that doesn't use new features can still be
compiled (but won't be binary compatible) with 0.9 and httpd-2.0.

>>Committing the change was the breakage.  It violated -our-
>>versioning rules. With the holidays, many eyes had been distracted
>>elsewhere, so now we are just playing catch-up to catch invalid
>No, it wasn't.  We've broken the API lots of times before in the 0.9.x series.  You just
want to enforce backwards-compatibility on APR when it isn't ready because a project that
uses APR requires backwards-compatibility.  Part of me says, "Tough."  httpd made a poor decision
relying upon a library that wasn't 1.0 with fixed version rules.

Quit it... we've been binary compatible for many successive httpd releases.
In fact, the last binary breakage was the 'widening' of the error number ranges,
and the poll change, which in hindsite I would have vetoed for later release
in the APR 1.0.  No matter, that's done and we're moving forwards.

We've proven the 90/10 rule that few changes need to break binary compat.
And we've tried to stick to it.  These changes we are discussing are minor, 
gratuitous, and introduce breakage just for the sake of breaking compatibility.

>IMHO, the proper thing to do is to branch off APR from where 2.0.43 went off, call that
API 1.0.  Apply relevant fixes as needed (bumping versions based on the version rules - i.e.
filepath_encoding bumps the minor).  Then, start on APR 2.0 with removal of deprecated functions
and we can change signatures as we like.  -- justin

No, we agreed a long time ago that versioning must be complete and immutable
before we call this APR 1.0.  Versioning APIs and macros shouldn't be changed
between 1.0, 2.0, 3.0 and so on, so let's take the time and get it right.  Branch
APR_0_9_BRANCH for maintenance alone, and move on with the final '1.0' 
rollout.  We are close, I agree.  But there is no reason for all of these deprecated
0.9 APIs to persist into 1.0, and there is no reason for httpd-2.0 to move onwards
to 1.0 (although you must be able to compile httpd-2.0 in either APR 0.9 or 1.0,
the two builds are just not binary compatible.)

Because httpd-2.0 is trying to remain binary compatible, it needs to stay back
on APR 0.9 for official binary releases.


View raw message