Greg Stein wrote:
Yes, we can change the API (that was allowed going from 1.3 to 2.0), but we were not allowed to remove features. Removing the fp from the API would have disabled this "feature" in mod_perl, among others.
When APR v1.0's first release candidate came out, there were loud calls saying "code XXX's API is broken, we can't release like this". So code XXX got fixed, and the process repeated for six release candidates. But APR v1.0 was cleansed of a lot of nonsense at it's final release.
I strongly suspect that when the first release candidate of httpd v2.2 comes out, people will say "wait, there is brokenness in code YYY, we can't go GA like this", and a call will be made for a fix and another release candidate.
So - do we embark on an effort to identify (and hopefully fix) broken code such as the exposing of the file pointer to modules before v2.2 goes GA, or do we target these sorts of breakage for httpd v2.4?
(There are other issues that need fixing, apparently there are some four or so config directives that once turned on cannot be turned off again inside a more specific config container.)
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
