trafficserver-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Peach <>
Subject Re: New APIs and ts.h vs experimental.h
Date Thu, 14 Feb 2013 18:55:09 GMT
On Feb 14, 2013, at 9:17 AM, Leif Hedstrom <> 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)

View raw message