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
