At 05:08 PM 3/16/2005, Paul Querna wrote: >William A. Rowe, Jr. wrote: >>-1 for apr-util / apr-iconv. >>Curt has identified a very significant issue; I will comment >>to that thread. Since the 'fix' should be fairly trivial, >>I think we should next release a version that deals with >>iconv/*.so's. > >I do not believe this is a valid reason to hold up these releases. This is not >a regression from any previous versions. This release fixes many other issues. >Once this issue is fixed, we can do another release.
Heaven forbid folks examine issues as they queue in :) +1 on release of 1.1.1 apr release, you are quite right. I will be voting +1 on httpd 2.1 alpha with this version. I will be voting -1 on taking httpd 2.1 to beta based on this version, and this specific conflict. Dev's don't mind having messed up and conflicting libraries (if you wonder where I've been, there ya go) messing up their systems. But end users are sure affected, and the point to a beta is pushing out code at our users/testers, as opposed to our devs/testers. I'm glad that Curt was as diligent as he was in following up the specific conflicts. My svn, httpd, all my packages are fragmented into their own trees. I don't expect either is true of the casual users/testers and any product that rolls these out in the same location or tries to use the envvar will end up jammed. We have jk2 (well, though it's deprectated), svn, apache, log4cxx, etc all who've come to trust apr - and we need to do all we can to continue to keep that trust. So +1 that 1.1.1 is better than 1.1.0 was. I am amused that some expect fast reaction to backport these fixes from trunk - the fixes that are ignored on list for months. I brought up the .rc/version issues 11/20, no feedback. David Barrett observed the problem 12/21, I committed the fix 2/7 and immediately got a flood of (productive) dialog, and immediately tweaked accordingly. If you aren't happy with my response time and attitude twords the "httpd 2.1 beta today!" scroll back to all the unanswered posts from many end users and fellow devs. In answer to the bigger Q - I would discourage anyone from adopting apr 1.0 and hope few have. apr 1.0 wasn't ready for prime time, to coexist on machines which had our original apr 0.9 installed. Now apr 1.1.1 is getting close to getting it right. If I voice that we should take things a bit more slowly and thoroughly, it's because I expect the same attention to detail from apr that folks expect from clib. After all, we are asking our users to give that much trust to our library. Bill
