What Ryan, Amit and I are asking for (and that most of the rest of the world who *doesn't* directly participate in apr/dev decisions) is that the API is right.
Again, I think there is confusion about the versioning rules: we can add in a brand new locking API into 1.1 - we just can't remove the old one until 2.0. So, I don't see the rationale for holding up 1.0 even if locking is 'broken.'
People have lived with this 'broken' API forever - I don't see the urgency.
Most likely scenario, the old locking API is deprecated in 1.1 when someone decides to get off their butt and 'fix' it. If someone happens to provide fixes in, say, two weeks before 1.0 is frozen - all the better, then we could rip out the 'broken API' for 1.0.
And, if the locking change were drastic enough to warrant a major binary-incompatible change, so be it: we issue 2.0. There's no reason we have to be conservative with our version numbers. We've done *that* for long enough. ;-)
One peripheral question - does this mean we are suggesting that apr-util is also at 1.0? Just asking.
Yes, I'd believe so. Probably same for apr-iconv, too. -- justin
