At 11:20 AM 7/2/2004, you wrote: >> At 07:29 PM 7/1/2004, Greg Stein wrote: >> >On Thu, Jul 01, 2004 at 05:38:34PM -0500, William A. Rowe, Jr. wrote: >> >> If we leave it, and side-by-side installs are broken, this does not >seem >> >> like a good initial release point for 1.0 :( >> > >> >"for the moment" >> > >> >Joe said it *twice*. Was it that non-obvious? >> >> No, it was obvious. However another party is rolling what he hopes to be >> the initial release on Friday, on his schedule. So if we *release* on Fri >> this would not be good. If it gets fixed next week and we can hold the >> release till next week, all would be lovely. >> >> Competing interests - and my message wasn't directed at Joe or Graham > >Damn. Competing interests? So, no-one else wants to get 1.0 out teh door. >Wow, must have been in dream land for a long, long time then...
Speed/Schedule of releasing 1.0 v.s. Completeness/Interoperability w/ 0.9. I for one am glad you've put folks feet to the fire so to speak, and laid out an ambitious plan for release of 1.0 this month :) Sometimes, until you try to implement, what seemed just fine in a build system turns out to be ineffective when confronted with rolling usable rpm's, deploying side by side with previous versions, etc. It wasn't until apr-1.0 that the apr/httpd side has ever really considered side-by-side installation issues, since we need the legacy 0.9 for some time to support httpd 2.0, and will need 1.0 installed and ready for httpd 2.1+, svn, jakarta-jk2 and so forth. Graham's RPM efforts have put a magnifying glass to every open parallel install issue - I think it's wonderful that he created the perfect example case whether he intended to, or not :) >> who have been working hard at the rpm/parallel install issues. It was >> directed at David who was hoping (expecting?) to roll an RC3 candidate >> today. > >Well, some form of explanation of the above would be more helpful than >cryptic comments. Sorry, it was my reaction to Greg's comments - which read (to me) that he was saying yes - table this for now, release 1.0.0, install and clobber the existing shared apr 0.9.5 install, then figure out how to get it right with release 1.0.1. That concerned me. >1/10 on helpfulness. I believe, with the possible exception of apr_finfo_t::ctime (and still asking for feedback), that APR is code-complete API stable for 1.0. With apr-iconv designated as a mutable implementation detail of the public apr_xlate interface, that is not an issue either. I spent no time in apr-util so I really don't have an opinion either way. If Graham's efforts, with Joe's useful feedback, produces a build system which cleanly lets 0.9 and 1.0 (and future releases) coexist, I'm satisfied we finished APR 1.0. I'd be very happy if we left apr-config alone (as 0.9), created apr-1-config or apr-1.0-config with a symlink named apr-1-config, and let the consumers attempt to use apr-[n..1]-config down to apr-config, based on what THEIR application is targeted at and capable of supporting. The version argument solution to apr-config also sounds like it could solve the problem. Bill
