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 23:02:10 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:
>> We are waiting on only one thing for APR 1.0, the full set of versioning
>> API functions.  I don't know where this stands, and I know Greg was
>> full of ideas/designs.  I'd like to see some feedback on this.
>The versioning mechanisms, functions, etc are all fully coded. They were
>that way before I spun up the 0.9.0 release. The versioning document
>outlines all of the human background for using that.


>> >>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.
>> Quit it... we've been binary compatible for many successive httpd releases.
>Happenstance. APR(UTIL) is free to change its API. You're missing that

And I suggest that *because* we aren't prohibited isn't a reason to just
introduce gratuitous breakage.

>> We've proven the 90/10 rule that few changes need to break binary compat.
>> And we've tried to stick to it.  These changes we are discussing are minor, 
>> gratuitous, and introduce breakage just for the sake of breaking compatibility.
>No. *YOU* have tried to stick to it. The versioning rules don't support this
>position. APR hasn't gone final, so it isn't bound to any contract.

I am not the only one who helped with this effort.  Even if we aren't bound,
there's no reason to be impolite when we can avoid it.

>> >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
>Agreed. I'd state that we make the 0.9.x branch for httpd, and change the
>HEAD to be 0.10.x. When we feel cozy, then we can pop to 1.0.

I guess I'm confused... what does 0.10.x gain us, when we are free to introduce
new APIs over the next generation?

In other words, what is wrong with blessing the current code as APR 1.0,
less all deprecated facilities?

If there are such issues right now, they belong in STATUS.  It's been a little
while since I visited that doc, so I'm wandering over there this evening.


View raw message