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 <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. > 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
