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.
