Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (hermes.apache.org: local policy)
Date: Mon, 20 Sep 2004 04:05:34 -0700
From: Greg Stein <gstein@lyra.org>
To: Stas Bekman <stas@stason.org>
Cc: APR Development <dev@apr.apache.org>
Subject: Re: renaming apr_filetype enum entries
Message-ID: <20040920110533.GB20672@lyra.org>
Mail-Followup-To: Stas Bekman <stas@stason.org>,
	APR Development <dev@apr.apache.org>
References: <414B7922.9050608@stason.org> <20040919134421.GB19299@lyra.org>
 <414DF83B.7080005@stason.org> <20040919213341.GB19990@lyra.org>
 <414E019D.9000702@stason.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <414E019D.9000702@stason.org>
User-Agent: Mutt/1.4.1i

On Sun, Sep 19, 2004 at 06:01:01PM -0400, Stas Bekman wrote:
> Greg Stein wrote:
>...
> >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.

That's what I'm saying: don't use them. Make your life easier and forget
the compat layer. For some people, they'll go ahead and code to the new
1.1 API, and they'll use the better symbol names.

But, your call. :-)

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

Both *WILL* be supported. There is no question to that. That's an absolute
baesd on the compat rules. The only way to avoid supporting both is to
shoot for a 2.0 release, and I'll veto any change that forces a 2.0 so
darned soon. I would expect to live in 1.x land for at least a couple
years. When our API gets too kludgy because of deprecation or whatever,
*then* we move to 2.0 and clear that out.

I believe the only question on the table is whether the short form macros
(e.g. APR_REG) are part of the API, or whether they are deprecated.

But they *will* still exist.

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

Just in httpd. APR can use the new macros, of course.

Cheers,
-g

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