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 22:58:02 GMT
At 03:43 PM 1/9/2003, Greg Stein wrote:
>On Thu, Jan 09, 2003 at 02:26:50PM -0600, William A. Rowe, Jr. wrote:
>
>> 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.
>
>I don't follow that. (prolly doesn't matter tho, based on other parts of my
>email)

I think this will make it clearer...

>> 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
>
>Agreed.
>
>> (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.)
>
>Nope. That jump in the major version implies an ability to break the source
>compatibility. We cannot release APR with a broken API, thus the need to
>allow changes to it.

The point is that we are sort of unlikely to change any APIs in such as way
as httpd-2.0 *itself* won't compile against APR 1.0.

We *could* do so, but I just don't see that as a *likelihood*.

So it's probably correct that if we provide any 'renamed' functions on the
APR 0.9 branch (keeping the deprecated wrappers for 3rd party authors)
and use the 'new' function names from 1.0/0.9, then it probably will build.

My point is that just 'because' it can, doesn't mean that we are free to
release httpd-2.0 binaries built on APR 1.0.  Because releasing such
a binary would break compatibility with the 3rd party module community.

Bill



Mime
View raw message