apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: The Release Candidate version number?
Date Thu, 27 Feb 2003 05:27:10 GMT
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

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

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)

> So assuming that the compatibility check is done at the boot time and I know 
> that some bug was fixed in:
> APR_MINOR_VERSION == 9 && APR_PATCH_VERSION == 2 && !APR_IS_DEV_VERSION
> can I use the compile time check?

If you're going to force it at boot time, then you wouldn't even need the
compile-time check [for the particular case we're talking about].

This kind of check would only be needed if there were source-level
incompatibilities, and you needed to code around those. For example, maybe a
symbol was introduced in a particular version. But then again, why not just
let the compilation fail for earlier versions -- you aren't going to run
against them anyways because of the boot/run time check.

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

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

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

Mime
View raw message