apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@lyra.org>
Subject Re: renaming apr_filetype enum entries
Date Sun, 19 Sep 2004 21:33:41 GMT
On Sun, Sep 19, 2004 at 05:20:59PM -0400, Stas Bekman wrote:
> Greg Stein wrote:
> >And the #ifndef wrappers are not needed. Just define the old names in
> >terms of the new.
> yes, yes, inside apr they won't be needed. They will be needed inside 
> projects supporting more than one apr generation.

IMO, projects should just use the API of the oldest major revision that
they can, and forget a bunch of compat stuff. If a project codes against
version 1.0, then it will work for everything after that.

> >4) httpd 2.2 (and 2.1) will be able to work just fine with 1.1 without any
> >   recompilation being needed, but you may be fighting a battle against
> >   people distribution a 2.2/1.0 combo.
> But this can be solved inside 2.2 by adding the ifdef-define-endif future 
> compatibility blocks as I've posted in my original proposal. So 2.2 will 
> transparently work with apr 1.0 and apr 1.1.

It will transparently work with both if we use APR_REG and friends. I
don't want to add a bunch of #ifdef code to httpd if it isn't needed.

> >Choose your path for mod_perl, but point #4 seems like it will pose
> >trouble for your users.
> it doesn't have much to do with mod_perl, besides us trying to keep the 
> Perl API consistent with C API, so it's easy to move between the two, 
> needing to know only one API.

Well, what you're really doing is providing a 1.1 API to all users. I
understand the motivation, but I'm not personally interested in that for

> So if that's fine with everybody and now Bill has pulled down his veto, 
> the only thing to wait for is the APR_1_1 branch to appear? Any plans for 
> that?

I'd like to see us move the APR modules over to SVN. We can then move the
trunk to branches/1.0.x/, and leave the trunk for 1.1 development.

I believe the last vote go-round had support for moving to SVN, so it was
just a matter of "make it so". (I'd have to go look, and if anybody
*doesn't* want to move to SVN, then please reiterate your concerns)


Greg Stein, http://www.lyra.org/

View raw message