Hey Cliff
Thanks again for your quick response.
I wanted to ask you (and the community) a few other quick questions.
Is it possible that 2.0.35 and 2.0.36 are compatible in terms of
dynamically loadable modules? I've compiled my module with both and both
modules can be loaded on both versions. Would it be safer to distribute
distinct module version for those two versions?
Is there a way in the httpd.conf file to check for server version before
loading a module? Haven't found anything like it in the directives...
Ben
At 12:04 7/15/2002 -0400, Cliff Woolley wrote:
>On Mon, 15 Jul 2002, [iso-8859-1] Beno�t Desmeules wrote:
>
> > My question is the following: does it always work like that? I mean, having
> > to recompile your Apache2 modules when using a new version of Apache2? Is
> > it specific to 2.0.39? I know some major security issue was resolved in
> > 2.0.39. What does someone that needs to deliver a commercial module should
> > do? Download all versions of Apache2 and compile his module with all of
> > them, having the binaries ready depending on what the client's version of
> > Apache2 is? Or force the client to use 2.0.39 since it has a big security
> > fix? What if the client refuses (remember, the client usually does not take
> > the decision you expect him to take :P)?
>
>The reason for this is that due to API changes between the two versions,
>we were forced to bump the Module Magic Number since modules would not
>necessarily retain binary compatibility with the new API.
>
>Look in ap_mmn.h for the full revision history of the MMN. Then go look
>at ap_mmn.h from Apache 1.3 ... as you can see, it's common to have MMN
>bumps for the first few sub-revisions, though things tend to settle down
>after that.
>
>In other words, if all you distribute is binaries, then yes, you'll have
>to have separate binaries for 2.0.35, 2.0.36, and 2.0.39. And another for
>2.0.40 when it comes out, most likely. Hopefully we'll soon settle the
>API down and *perhaps* 2.0.40 will see the last or next-to-last 2.0.x
>major number bump. Perhaps.
>
>--Cliff
