apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: The Release Candidate version number?
Date Thu, 27 Feb 2003 05:31:50 GMT
Greg Stein wrote:
> On Thu, Feb 27, 2003 at 03:55:13PM +1100, Stas Bekman wrote:
> 
>>Greg Stein wrote:
>>...
>>
>>>You have to use a runtime check. It is too easy to slide in a library that
>>>is different from what you compiled against. Our compatibility guidelines
>>>are designed specifically to enable that kind of forward/backward change.
>>>
>>>Compile-time checks are only useful to look for API changes as a way to
>>>decide how to call into APR. If the API is the same, and you're trying to
>>>test for an underlying bug, then you'll need to use a runtime check.
>>>
>>>And all of this remains a bit fuzzier during pre-1.0 days. It might be
>>>possible in certain cases to look for bug fixes, and rely on incompatible
>>>APIs between patch levels to prevent the erroneous usage of an older
>>>library. But that's your call, and to be made on a case-by-case basis.
>>
>>Greg, I'm not following you 100%.
>>
>>If the app was compiled against specific apr_version.h, why not have a check 
>>at the boot time whether the binary library matches? That's what httpd does 
>>for modules it tries to load. Can't we do the same for apr?
> 
> 
> Yes, you could do that, but I'd say that it is circumventing the desired
> usage policy of the library.
> 
> To be concrete:
> 
> * the APR versioning policy implies that we number releases as
>     MAJOR.MINOR.PATCH

oops, I've completely forgotten about the MAJOR :)

> * 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 :-)

Nope, I should have said MAJOR.MINOR. And no, not requiring a specific a 
minimum MAJOR.MINOR but only checking that the library in use is the same as 
the one the app that was compiled against.

[...]

> I would normally advocate trying to run against as many versions as
> possible, and using runtime checks to arbitrate your usage of the library.
> If you ever code up a compile time check, and you compile against rev X.Y,
> then your installer should require that (at least) X.Y has been installed.
> [ cuz you might not even be able to load/link against X.(Y-1) ]

That's clear.

>>Finally the run-time check that you are talking about is the following?
>>APR_DECLARE(void) apr_version(apr_version_t *pvsn);
> 
> 
> Yup.
> 
> Fetch the structure and look at its values. It has everything you'd need.

but this incurs run-time overhead. So if I could avoid it, it's a goodness.

__________________________________________________________________
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


Mime
View raw message