On Feb 14, 2013, at 9:17 AM, Leif Hedstrom <zw...@apache.org> wrote:
> Hi all,
>
> This has been discussed a few times, but I don't think we agreed on a
> standard or "best practices". As you all know, we have made a promise
> ("contract") to not break APIs or ABIs within major releases. This implies
> that once an API goes into ts/ts.h, we can't change the prototype (we can
> change/fix the implementation though, of course).
>
> We have an experimental API include file, ts/experimental.h, where we have a
> bunch of APIs which has not been considered stable or frozen. I have in the
> past moved a number of APIs from this file to ts/ts.h. There are still quite
> a few APIs in this file, some which I think can be promoted, some which I
> have serious concerns about (such as the second CacheVC API, it's just wrong
> :).
>
> Here's the question / thought: When we add new APIs to the core, should they
> go into ts/ts.h or ts/experimental.h ? Both has pros and cons, as usual, the
> strength of ts/experimental.h is that it allows us to modify prototypes of
> new APIs without breaking the guaranteed API / ABI contract that we have for
> ts/ts.h.
>
> What do you all think?
I've been guilty of adding a number of APIs directly to ts.h. As I've stated in
the past I would like to see a more formal API review process. I'm fine with
pushing APIs through experimental.h, but I don't want that to be a substitute
for a formal API review, and I would like to see an additional process for
promoting APIs from experimental to stable (eg. we review all experimental APIs
at the start of a new release cycle)
J
