httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Gaudet <>
Subject RE: binary backwards compatability.
Date Thu, 30 Mar 2000 01:39:00 GMT
On Wed, 29 Mar 2000, Greg Stein wrote:

> On Wed, 29 Mar 2000, Dean Gaudet wrote:
> > ... lots o' stuff ...
> I gotta go with Dean, partially. Trying to maintain backwards compat is
> awfully difficult, and given the experiences with Linux, it is
> "acceptable" in an Open Source environment.
> However: I like Ryan's suggestion for an *optional* version checking
> function. If the function is not provided, then we use the current check.
> If the function does it exist, then it will be called IFF the module's
> major version is >= Apache's major version. The module can make allowances
> for running against *old* Apache servers (NOT newer ones!).

so then 3rd party module writers would override the check, because they
don't want to set up any infrastructure for "frequent" releases of their
code, and folks using 3rd party modules will see odd segfaults and other
bizarre happennings with their server.

and folks supporting apache will have to find out the versions of all 3rd
party modules in use, and have to guess if those modules are causing the
bizarro behaviour the customer is reporting.

> Consider the M_INVALID change: I could write a module today that
> understands the current and old values, and compensates accordingly.

how would it know about the new value?  this is a compile-time constant.

> Likewise, I might have two code paths for dealing with different semantics
> of some API functions. Maybe my module dynamically looks up exported
> API functions, allowing dynamic use of certain functionality.

how would you know about new API functions?  you're talking about
predicting the future.

> I agree with Dean that a module should not be allowed to run *if* Apache
> is newer than the module (as defined by MAJOR); there is no way the module
> could know if its use of Apache has changed or not.
> [ I think that Dean was only looking in one direction of time... ]

the other direction is uninteresting -- if a vendor has to relesae a new
version anyhow they might as well leave older versions up on their


View raw message