Mailing-List: contact bugs-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache HTTPD Bugs Notification List" <bugs@httpd.apache.org>
Date: 7 Sep 2002 20:25:09 -0000
Message-ID: <20020907202509.8039.qmail@nagoya.betaversion.org>
From: bugzilla@apache.org
To: bugs@httpd.apache.org
Cc: 
Subject: DO NOT REPLY [Bug 12388]  -
    Binary incompatibilities for modules developed with different builds of
 Apache v2.

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12388>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12388

Binary incompatibilities for modules developed with different builds of Apache v2.


------- Additional Comments From cm@cmunt.demon.co.uk  2002-09-07 20:25 -------
Thanks for the response, but I believe the point I was making has been missed.

I am aware that 'only a recompile' of modules is necessary between builds of 
Apache.  In fact, our code has remained unchanged for every single release of 
Apache v2.  I believe the issue that needs to be addressed is that commercial 
vendors of modules do not want to have to ship several different versions of the 
binaries for different builds of Apache - it just creates a support and 
maintenance headache.  Just one module binary per major upgrade (e.g. Apache 
v1.3 to 2.0) would be good.  Also, for many commercial vendors, simply sending 
the source code to the end users is not an option.  Certainly, our customers 
would not want the responsibility for building, what is after all, a pivotal 
piece of connectivity software on site.

I understand that the Developers of Apache want to push forward with new 
features, but I believe that a lack of regard for backwards compatibility 
becomes counter-productive in the end.  It simply becomes too much hassle for a 
company to upgrade Apache and its associated software. 

I believe there is a place for an API like ISAPI or NSAPI where, providing one 
sticks to the original core functionality, the binary incompatibilities are few 
and far between.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org