apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@apache.org>
Subject Re: Showstopper ... was: Tagged the tree
Date Thu, 09 Jan 2003 19:27:29 GMT
--On Thursday, January 9, 2003 1:07 PM -0600 "William A. Rowe, Jr." 
<wrowe@rowe-clan.net> wrote:

> 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

View raw message