[PATCH] D12685: Document the stability policy for LLVM-C APIs.

[Mehdi Amini via llvm-commits]

> On Sep 15, 2015, at 3:20 PM, Amaury SECHET <deadalnix+llvmreview at gmail.com> wrote:
> 
> deadalnix added a comment.
> 
> @echristo the C APi test is not intended as to freeze the API, but as to make sure that things are done intentionally. It follow the recent landingpad change fiasco.
> 
> If a change is made that break the C API, then the test is going to break. Either this breakage is intentional, in which case the test can be updated to reflect the change, or the breakage is not intentional and can be fixed.
> 
> The test is intended to cover read and write IR, which seems like a minimum to have for the API to be useful.
> 
> Generally, I think the best effort policy proposed here is the right balance.


 While I can see this as reasonable, I still this as an *opinion* that is not backed by any data. 
Any direction for the C API(s) should be driven by a survey of the existing (and potential) client use case and their need. It is not clear that this “reasonable” tradeoff is matching perfectly the needs of the projects around, vs some auto-generated API that wouldn't carry any more guarantee than the C++ one. 
For instance libLTO is providing “perfect" two-way compatibility that is leveraged by ld64. If we were to switch to such a “balanced” policy, then there is not much difference with the bindings with how it is of interest for this external project.

— 
Mehdi