apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: The Release Candidate version number?
Date Thu, 27 Feb 2003 15:52:08 GMT
At 11:27 PM 2/26/2003, Greg Stein wrote:

>* further, it states that versions differing only in the PATCH number should
>  be completely interchangeable -- only bug fixes. no application should see
>  any behavior change, other than to see a reduction in bugs
>
>Thus, if you write the application to require a specific PATCH level, then
>you're defeating the intended policy. Doable, of course, but not nice :-)

No, not really, because..

>I guess the app could say, "hey. there was a bug fix in patch level 3 that I
>must have; I'll refuse to operate with anything earlier." So it is probably
>okay to have harder checks; I would just hope that we don't force apps into
>that situation. Or that apps can find workarounds or degraded functionality.
>(thus giving great flexibility at install time)

This is very close to what Stas is saying - he has a workaround for the
'broken' flavor of apr_uri_unparse, but only plans to apply the workaround
when it's required.

We might have to back up one bit here ... mod_perl will probably always
be bound to specific apr/apache subversions at the time it's built (or maybe
with enough magic, at runtime) because it exposes our newest fn's as soon
as they become available on the -dev work branch.  They will always be
'deep into the guts' of the API.

However, to Stas; you might consider requiring that the user upgrades their
APR to something respectable at some point.  Remember that pre-1.0 libs
are all development/pre-release, and it might be easier to request that your
users grab the 0.9.2 release or later version.  Even httpd 2.0.40 should still 
build just fine against APR 0.9.2.

Bill



Mime
View raw message