apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Misch <n...@cs.caltech.edu>
Subject Re: documented 1.0 showstoppers
Date Fri, 04 Jun 2004 20:53:59 GMT
On Fri, Jun 04, 2004 at 01:33:56PM -0700, Stas Bekman wrote:

> >>Should it be s/APR_/APR_FILETYPE_/ and s/APR_/APR_FINFO_/ or something else?
> >>Like so?

> >Do that on a clean checkout, compile, and check the diff for sanity.  I don't
> >think there's much else to it.

> Thanks Noah, but this is exactly why I didn't do that and asked here first. 
> It's not about just changing the API, since you will break any application 
> that relies on that. You must provide backwards compatibility which should 
> be deprecated and will be cut off at 1.0 release. That's the part I'm not 
> sure about.

You can add/remove anything in a major release, and I think it's reasonable to
treat CVS HEAD as "what could suddenly become 1.0".  Projects seeking backward
compatibility should be using the latest 0.9.X branch.  That's my understanding
of the policy, anyway.

That said, it's not particularly harmful for existing projects to keep using
this old API, so maintaining it in parallel for convenience through 2.0 might be
worthy.  Perhaps something like the following for each removed symbol?

static const apr_filetype_e APR_REG __attribute__((deprecated)) = APR_FILETYPE_REG;

Then add some configuration / #define stuff to only set the attribute for
compatible compilers.

If you also hope to do this to 0.9.X, then you could do something like the above
to comply with the versioning rules.

Mime
View raw message