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.
Coolness. >> >>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 >point. 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. Bill
