On 9/5/06, Ruediger Pluem <[EMAIL PROTECTED]> wrote:
On 09/05/2006 03:08 PM, wrote: > Author: trawick > Date: Tue Sep 5 06:08:15 2006 > New Revision: 440337 > > URL: http://svn.apache.org/viewvc?view=rev&rev=440337 > Log: > Replace ap_get_server_version with ap_get_server_banner() and > ap_get_server_description().
Two comments: 1. If we stick to AP_DECLARE(const char *) ap_get_server_version(void); and do #define ap_get_server_banner ap_get_server_version I guess we can backport this without breaking binary compatibility and the need for a major bump (on trunk the major bump makes sense to me). Given the fact that we want to calm certain FAQ requests it would make sense to me to backport it.
I'm hoping to backport it even if just to stop maintaining my own patch to get juicy info in the error log at startup when the user has "ServerTokens Prod" ;) I'd go with Brian's plan to preserve ap_get_server_version(). It also allows modules to do the right thing (call the function specific to what they're trying to do) for Apache >= 2.2.4. They can use the old function for compatibility or the new function if it helps them.
2. On trunk shouldn't we add #define ap_get_server_version ap_get_server_banner
my 2 cents: for trunk, we'd like third-party modules to go ahead and decide which API to call based on what they are doing with the information; if they still load fine courtesy of a macro or ap_get_server_version() function, some folks will miss that giant hint include/ap_compat.h might be the place to put a macro definition for compatibility (even though it says compatibility with 1.3 in the doc)
While this still breaks binary compatibility it would allow modules using ap_get_server_version to compile against trunk. Maybe we could mark ap_get_server_version as deprecated on trunk. I am not a macro expert, but maybe it is even possible to spit out a warning if ap_get_server_version is used. Thoughts?
I think we'd mark it deprecated on 2.2.x branch if/when we backport the new APIs and it simply disappears on trunk. I'm anxious to hear more opinions.
