Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Errors-To: <wrowe@rowe-clan.net>
Message-Id: <5.1.0.14.2.20020510213219.02350290@pop3.rowe-clan.net>
Date: Fri, 10 May 2002 21:39:17 -0500
To: dev@apr.apache.org, dev@httpd.apache.org
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Subject: Re: Symbol renames
In-Reply-To: <00ca01c1f86f$03c84780$3700000a@KOJ>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed

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.