You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Ryan Bloom <rb...@covalent.net> on 2002/05/11 00:07:02 UTC
Symbol renames
Symbol renames in APR are going to cause a problem for the web server.
Apache 2.0.36 is using the same major MMN as 2.0.35, but it isn't
compatible, because apr_explode_time was removed (as a single example,
there are more). We need to have some way to fix these problems.
My opinion would be that symbol renames stop becoming macros. Instead,
the function is renamed, and a new function is added that wraps the old
function. This is EXACTLY what Greg wrote in his doc earlier today.
Also, the apr_compat.h file should be removed now. Any further compat
macros need to be put in the same file as the original function/macro.
If we use the apr_compat.h header, then we haven't made things backwards
compatible, because they need to add the new header to their source
file.
Ryan
----------------------------------------------
Ryan Bloom rbb@covalent.net
645 Howard St. rbb@apache.org
San Francisco, CA
Re: Symbol renames
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 05:07 PM 5/10/2002, Ryan Bloom wrote:
>Symbol renames in APR are going to cause a problem for the web server.
>Apache 2.0.36 is using the same major MMN as 2.0.35, but it isn't
>compatible, because apr_explode_time was removed (as a single example,
>there are more). We need to have some way to fix these problems.
The first solution is to stop moaning about MMN bumps, as the world did.
Had I reread my own notes that I posted much earlier, I would have chosen
to ignore the hew and cry. Those time fn changes were killer.
>My opinion would be that symbol renames stop becoming macros. Instead,
>the function is renamed, and a new function is added that wraps the old
>function. This is EXACTLY what Greg wrote in his doc earlier today.
++1 and then some. The only alternative is to make the _NEW_ fn name as
the macro then transition at the next point bump (e.g. 2.1). Changing the fn's
name, even with a macro for the old name, will never be binary compatible
since that binding is gone from the new binary, and old binaries won't bind.
>Also, the apr_compat.h file should be removed now. Any further compat
>macros need to be put in the same file as the original function/macro.
>If we use the apr_compat.h header, then we haven't made things backwards
>compatible, because they need to add the new header to their source
>file.
A [somewhat reserved] +1. I'm willing to say anything prior to the release
of 2.0.35 should be dropped, except for ap_ -> apr_ macros, which should
be considered for an httpd-2.0/include/ap_compat_13.h module [unsupported,
for reference only, all the rest of the usual disclaimers, etc.] We may be
'done' with 2.0 and contemplating the filtering overhaul for 2.1 [not ignoring
the bugfix work ongoing.] But the rest of the world hasn't caught up with us
just yet.
I would also suggest we immediately _FIX_ the time function problem and
create those missing functions so that .35 is restored in .37.
Re: Symbol renames
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 05:07 PM 5/10/2002, Ryan Bloom wrote:
>Symbol renames in APR are going to cause a problem for the web server.
>Apache 2.0.36 is using the same major MMN as 2.0.35, but it isn't
>compatible, because apr_explode_time was removed (as a single example,
>there are more). We need to have some way to fix these problems.
The first solution is to stop moaning about MMN bumps, as the world did.
Had I reread my own notes that I posted much earlier, I would have chosen
to ignore the hew and cry. Those time fn changes were killer.
>My opinion would be that symbol renames stop becoming macros. Instead,
>the function is renamed, and a new function is added that wraps the old
>function. This is EXACTLY what Greg wrote in his doc earlier today.
++1 and then some. The only alternative is to make the _NEW_ fn name as
the macro then transition at the next point bump (e.g. 2.1). Changing the fn's
name, even with a macro for the old name, will never be binary compatible
since that binding is gone from the new binary, and old binaries won't bind.
>Also, the apr_compat.h file should be removed now. Any further compat
>macros need to be put in the same file as the original function/macro.
>If we use the apr_compat.h header, then we haven't made things backwards
>compatible, because they need to add the new header to their source
>file.
A [somewhat reserved] +1. I'm willing to say anything prior to the release
of 2.0.35 should be dropped, except for ap_ -> apr_ macros, which should
be considered for an httpd-2.0/include/ap_compat_13.h module [unsupported,
for reference only, all the rest of the usual disclaimers, etc.] We may be
'done' with 2.0 and contemplating the filtering overhaul for 2.1 [not ignoring
the bugfix work ongoing.] But the rest of the world hasn't caught up with us
just yet.
I would also suggest we immediately _FIX_ the time function problem and
create those missing functions so that .35 is restored in .37.