apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: svn commit: r1128885 - in /apr/apr/trunk: build/apu-conf.m4 build/apu-ldap.m4 configure.in
Date Mon, 06 Jun 2011 23:13:11 GMT
On 07 Jun 2011, at 12:53 AM, William A. Rowe Jr. wrote:

> 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).

jorton reviewed it first, and all of his requested changes have been  
applied where they made sense. jimjag reviewed it a while back and  
+1'd it as it stood. That's 3 (including me), just waiting for you to  
make it 4.

> 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.

The only API I am worried about from a backport perspective is  
apr_crypto in apr-util v1.4, as it's new. Everything else is apr v2.0  
and onwards, as per our API rules.

> I am still waiting for your answer to who the other consumers are of  
> apr_ldap.

No idea. For many years, we have been a general API that offered a  
general portability library to any app that wants it, the days of us  
being part of httpd are long gone. We set the standard for how APIs  
should be managed, and that goes for all of our library.


View raw message