httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruediger Pluem <rpl...@apache.org>
Subject Re: Ship 1.3.0 apr in httpd 2.2.9
Date Sat, 12 Apr 2008 19:41:53 GMT


On 04/11/2008 04:39 PM, William A. Rowe, Jr. wrote:
> So here's a thought from Davi's^WColm's APR talk in speaking with
> chipig, jorton and others...
> 
> We have several inheritance quirks addressed by 1.3.0 apr, and the
> new memcache, ssl and other features are present in 1.3.  The features
> in APR[-util] 1.3 would be a definite benefit, today.
> 
> When we add a few new functions to HTTPD - we bump the MMN and then
> guarantee that these functions are binary compatible from that given
> MMN bump ... all older builds against that HTTPD are binary forward
> compatible until we move along to 2.4.
> 
> In APR - we guarantee backwards binary compat... apr 1.{any} will
> continue to behave once we we bump the version minor.
> 
> Combine these, and it seems that with a Minor MMN bump, we can throw
> the switch to require APR 1.3.x (or later) for the remaining life
> of httpd 2.2.
> 
> The other side effects of requiring apr 1.3 over 1.2.x all seem to be
> build related and really have no binary compatibility issues whatsoever.
> 
> So if APR ships 1.3.0 - would we be prepared to accept 1.3.0 as the new
> minimum version, modulo the minor MMN bump?

I thought about this for a while. To be honest I always mistrust software
that was not widespread and thus tested in real life before (that has
nothing to do with APR or httpd and is no insult on either project), but
yes we need to start this at some point of time.
With APR I guess it would not be helpful to just release 1.3.0 or do some
alpha / beta release and wait for the reports coming in. We actually need
to ensure that it is used otherwise we do not get sufficient test feedback.

So here is my idea:

Ship 1.3.0 with httpd 2.2.x, but do *not* make httpd dependent on 1.3.x
now. Wait for this until 1.3.x has settled a bit more and things like
the ones Nick mentioned are fixed.
Furthermore I could image adding apr-1.2.x / apr-util-1.2.x directories
to our tarballs for the next release to make it easy for users to fall
back to 1.2.x if there is some kind of regression in 1.3.0.
But it might be also ok to require the users in these cases to download
1.2.x separately drop in the sources and call buildconf.

Regards

RĂ¼diger



Mime
View raw message