You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by William A Rowe Jr <wr...@rowe-clan.net> on 2022/01/16 21:38:09 UTC

Re: Get rid of APU api in favor of APR for apr/turk

On Mon, Dec 13, 2021 at 7:43 AM Mladen Turk <mt...@apache.org> wrote:
>
> On 08/12/2021 08:33, Ruediger Pluem wrote:
> > I assumed this as a trunk/2.0 only proposal. Is my assumption wrong?
> >
>
> Yes, trunk only.
> Just a simple copy/paste leftover cleanup, mostly for internals

Within that scope, yes, make it happen. Temp macros for the lifespan
of 2.0.x seems appropriate,
ending at release 2.1.0

Re: Get rid of APU api in favor of APR for apr/turk

Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Sun, Jan 16, 2022 at 11:08 PM Greg Stein <gs...@gmail.com> wrote:
>
> On Sun, Jan 16, 2022 at 11:02 PM William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>
>> People will need to change their code to apr-2.x. But in the interim,
>> apr-util 1.7.0
>> aught to have a compat layer to let authors adopt apu_ -> apr_ conventions
>> ahead of time. Do we concur?
>
>
> If a release is coming up, then sure: adding new APIs to 1.7 is totally in-bounds.

There are 1.7 and 1.8 releases arriving this month. I meant to type 1.8 for the
new compat wrappers, but you are right, we could inject macros any time.
We just can't change exported symbols within the lifespan of 1.X where X is
any integer.

Re: Get rid of APU api in favor of APR for apr/turk

Posted by Greg Stein <gs...@gmail.com>.
On Sun, Jan 16, 2022 at 11:02 PM William A Rowe Jr <wr...@rowe-clan.net>
wrote:

> On Sun, Jan 16, 2022 at 10:46 PM Greg Stein <gs...@gmail.com> wrote:
> >
> > On Sun, Jan 16, 2022 at 3:38 PM William A Rowe Jr <wr...@rowe-clan.net>
> wrote:
> >>
> >> On Mon, Dec 13, 2021 at 7:43 AM Mladen Turk <mt...@apache.org> wrote:
> >> > On 08/12/2021 08:33, Ruediger Pluem wrote:
> >> > > I assumed this as a trunk/2.0 only proposal. Is my assumption wrong?
> >> >
> >> > Yes, trunk only.
> >> > Just a simple copy/paste leftover cleanup, mostly for internals
> >>
> >> Within that scope, yes, make it happen. Temp macros for the lifespan
> >> of 2.0.x seems appropriate,
> >> ending at release 2.1.0
> >
> >
> > Given the clarification this is for 2.x, then I'd say: skip the temp
> macros. They couldn't be removed in a point release anyways.
> >
> > That said, I'd be +0.5 for an "apu_legacy.h" to assist with people
> porting 1.x code to 2.x. Downstream users would just throw in that #include
> into appropriate source files, and call it a day. That header would be
> super easy to maintain going forwards (ie. rarely, if *ever* change), so
> wouldn't really be a maintenance burden.
>
> I think we totally agree... and apr_legacy.h can be dragged in by apr.h
> IMHO.
>

I dunno about putting that into apr.h (my thought is if your compile fails,
then add the header), but am only -0 .. no complaints.


>
> KISS.
>
> People will need to change their code to apr-2.x. But in the interim,
> apr-util 1.7.0
> aught to have a compat layer to let authors adopt apu_ -> apr_ conventions
> ahead of time. Do we concur?
>

If a release is coming up, then sure: adding new APIs to 1.7 is totally
in-bounds.

Cheers,
-g

Re: Get rid of APU api in favor of APR for apr/turk

Posted by William A Rowe Jr <wr...@rowe-clan.net>.
On Sun, Jan 16, 2022 at 10:46 PM Greg Stein <gs...@gmail.com> wrote:
>
> On Sun, Jan 16, 2022 at 3:38 PM William A Rowe Jr <wr...@rowe-clan.net> wrote:
>>
>> On Mon, Dec 13, 2021 at 7:43 AM Mladen Turk <mt...@apache.org> wrote:
>> > On 08/12/2021 08:33, Ruediger Pluem wrote:
>> > > I assumed this as a trunk/2.0 only proposal. Is my assumption wrong?
>> >
>> > Yes, trunk only.
>> > Just a simple copy/paste leftover cleanup, mostly for internals
>>
>> Within that scope, yes, make it happen. Temp macros for the lifespan
>> of 2.0.x seems appropriate,
>> ending at release 2.1.0
>
>
> Given the clarification this is for 2.x, then I'd say: skip the temp macros. They couldn't be removed in a point release anyways.
>
> That said, I'd be +0.5 for an "apu_legacy.h" to assist with people porting 1.x code to 2.x. Downstream users would just throw in that #include into appropriate source files, and call it a day. That header would be super easy to maintain going forwards (ie. rarely, if *ever* change), so wouldn't really be a maintenance burden.

I think we totally agree... and apr_legacy.h can be dragged in by apr.h IMHO.

KISS.

People will need to change their code to apr-2.x. But in the interim,
apr-util 1.7.0
aught to have a compat layer to let authors adopt apu_ -> apr_ conventions
ahead of time. Do we concur?

Cheers,

Bill

Re: Get rid of APU api in favor of APR for apr/turk

Posted by Greg Stein <gs...@gmail.com>.
On Sun, Jan 16, 2022 at 3:38 PM William A Rowe Jr <wr...@rowe-clan.net>
wrote:

> On Mon, Dec 13, 2021 at 7:43 AM Mladen Turk <mt...@apache.org> wrote:
> > On 08/12/2021 08:33, Ruediger Pluem wrote:
> > > I assumed this as a trunk/2.0 only proposal. Is my assumption wrong?
> >
> > Yes, trunk only.
> > Just a simple copy/paste leftover cleanup, mostly for internals
>
> Within that scope, yes, make it happen. Temp macros for the lifespan
> of 2.0.x seems appropriate,
> ending at release 2.1.0
>

Given the clarification this is for 2.x, then I'd say: skip the temp
macros. They couldn't be removed in a point release anyways.

That said, I'd be +0.5 for an "apu_legacy.h" to assist with people porting
1.x code to 2.x. Downstream users would just throw in that #include into
appropriate source files, and call it a day. That header would be super
easy to maintain going forwards (ie. rarely, if *ever* change), so wouldn't
really be a maintenance burden.

Cheers,
-g