Thanks everyone for their critical eyes and testing on 1.2.8/0.9.13, the results for the releases were unanimous, and I add my own +1 to all of the packages.
Unfortunately, the initial .mak/.dep file creations for win32 were wrong for apr-util v 0.9.13 package, and the -win32-src.zip packages for apr-iconv were also created incorrectly by me with hardcode local paths. Since this is a trivial post-release packaging snafu, I've simply re-extracted the .mak+.dep files and replaced the affected .zip's in /dist/apr/ for windows source users. The apr-iconv issues go a bit deeper though - there is alot of warning noise building apr-iconv on VC2005. It seems time to refresh those packages so that users of the modern compiler can use it without incident. I'd like to plan to go ahead a roll apr-iconv packages by early next week. In the case of 0.9.13 this includes the fixes for windows compilation, and a small fix to the ucs2 byte order mark (it was added to streams only on continuation of stream, it should have only been added on start-of-stream). The same fixes apply to 1.2.0 - but here is where I could use a hand (knowing how crazy my schedule's been). We didn't correctly tag the resulting .so for unix as libapriconv-1.so (missing -1) in earlier versions. It's NOT binary compatible with libapriconv[-0].so and this is a bad thing. Fixing it results in a behavioral/expectation change, thus moving 1.1 -> 1.2. I realize next-to-nobody is trying to build apr-iconv-1 on unix, and even for windows by 2.0 I'd like it to be gone in favor of citrus. But that said, it's still out there, and we may as well lug it along for one last technically correct release before archiving the effort. Any volunteer to help on the unix build side? Bill
