On Sun, Jan 16, 2022 at 10:46 PM Greg Stein <gst...@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
