No... as Jeff reminded us, APR 0.9.x must retain backward-compat.
No, our version rules were never meant to be enforced prior to 1.0. (The versioning rules are perfectly clear on this.) People only want backwards-compatibility because of httpd 2.0. The cart is dragging the horse here.
No, as I original proposed, httpd-2.2 will target APR 1.0. In fact, httpd-2.2 won't even be released until APR hits that magic number. All the old cruft deprecated over the development history of APR 0.9.x will evaporate.
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.
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 commits.
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.
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
