Thanks for your prompt response. The pointer to the MAGIC_NUMBER info is appreciated.
FYI I had read the CHANGES file closely for any mention of things that would break the module compatibility and I was unable to find any mention of it. Keep up the great work!!! -- Tom Jordahl [EMAIL PROTECTED] Allaire Corp. http://www.allaire.com [EMAIL PROTECTED] wrote: > > [In order for any reply to be added to the PR database, ] > [you need to include <[EMAIL PROTECTED]> in the Cc line ] > [and leave the subject line UNCHANGED. This is not done] > [automatically because of the potential for mail loops. ] > > Synopsis: Modules compiled with 1.3.0 wont load in 1.3.1 or later > > State-Changed-From-To: open-closed > State-Changed-By: akosut > State-Changed-When: Thu Jul 30 09:24:58 PDT 1998 > State-Changed-Why: > You are correct that changing the MODULE_MAGIC_NUMBER for > minor releases is inconvenient for module authors who ship > binary-only modules. This is why we do it as little as > possible; if you'll note, Apache 1.2.0 has the same > MODULE_MAGIC_NUMBER as 1.2.6. > > However, if you'll note (http://dev.apache.org/mmn.txt has > a list of some of the reasons MODULE_MAGIC_NUMBER has been > changed), API changes has to be made for 1.3.1. These were > changes that should have been in 1.3.0, but we forgot. > > Some of these, such as the renaming of functions, do affect > binary compatibility, and any module compiled for 1.3.0 > that uses them would not work with 1.3.1. This is why the > MODULE_MAGIC_NUMBER check exists. > > However, we are aware of the problem. For now, we can only > suggest you produce a 1.3.1 version of your module and > reccomend your users upgrade to 1.3.1 (the Apache Group > reccomends this as well). > > As well, it is a priority for Apache 2.0 to include a > mechanism for ensuring backwards-compatibility for modules > when we make API changes. > > Thanks for using Apache.
