On 6/6/2011 5:30 PM, Graham Leggett wrote: > > Given that apr_crypto is in the > soon-to-see-light-of-day apr-util v1.4, and we don't want to have APIs change > unnecessarily, apr_crypto needs to be perfected first. That's some backports > and some > polishing away.
Well, exactly. apr_crypto must be reviewed if anyone wants to ship it in 1.x, apr_ldap and apr_dbd probably don't change in generation 1.x (not unless there is some hugely compelling reason for backport). apr_dbd must be changed prior to apr 2.0 if there is anything we strongly believe must be corrected for GA. E.g. nothing can be dropped or changed from apr 2.1 (new functions, yes, deprecated, yes, changed, no, dropped, no). apr_ldap is new development, it doesn't need to change for apr 2.0. That is to say, a fresh apr_ldap can be introduced in apr 2.1 or 2.0. So it's just a matter of volunteer time, energy and momentum. In the interim it is where it belongs, at it's single consumer. I am still waiting for your answer to who the other consumers are of apr_ldap.
