apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: renaming apr_filetype enum entries
Date Sun, 19 Sep 2004 22:01:01 GMT
Greg Stein wrote:
> 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.

mod_perl 2.0 needs to support apr 0.9.x (as long as 2.0.x requires it) and 
it'll probably support 2.2 as well. So if those defines are added in apr 
1.1 we can't use them w/o the compat layer, to support older libapr.

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

Right, but there were just few opinions so far of whether both should be 
supported or not. I just thought that the decision wasn't cast in stone yet.

On the other hand if httpd/apr provide backward compatibility macros it's 
almost the same as having both, if there is no deprecation cycle.

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

You mean, you'd like to keep the old short defines used across httpd? and 
inside libapr?

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

Sure, whatever it takes.


-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

Mime
View raw message