Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Message-ID: <3E5E929E.5060408@stason.org>
Date: Fri, 28 Feb 2003 09:35:10 +1100
From: Stas Bekman <stas@stason.org>
Organization: Hope, Humanized
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826
MIME-Version: 1.0
To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Cc: Greg Stein <gstein@lyra.org>, dev@apr.apache.org
Subject: Re: The Release Candidate version number?
References: <3E5D9A31.8080000@stason.org>
 <5.2.0.9.2.20030226180456.01e52ff8@pop3.rowe-clan.net>
 <2147483647.1046276747@[10.0.1.15]> <3E5D65B6.3090104@stason.org>
 <20030226201431.C21189@lyra.org> <3E5D9A31.8080000@stason.org>
 <5.2.0.9.2.20030227094347.03adc5d8@pop3.rowe-clan.net>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

William A. Rowe, Jr. wrote:
> 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.

It actually works much simpler for modperl 2.0 so far. We work with httpd, 
which always includes the latest apr, so when people pick the latest httpd, 
they get the latest apr.

However since mp2 supports Apache versions as early as 2.0.36, we have to be 
back-compatible with older aprs as well. And once this compatibility layer is 
in place, it doesn't really matter if we suggest to upgrade to a newer apr or not.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com