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

[James Y Knight via llvm-commits]

jyknight added a comment.

Repeating Eric's proposal (at least, I think the one he means):

> What I'm proposing is that we make the C API that exists in tree a bindings API that has the same stability guarantees as the C++ API. Honestly it'll probably much more stable, but at least then we won't have to worry or revert work because the C API was "too close to the machine" or rather the C++ code.  This means that someone that wants a stable C API can go off and develop one (tests and all) and we can possibly look at bringing it back into tree at some point in the future. For example, if someone comes up with a good "libjit" api then we can look at how the API design works and make sure it's general enough that it's not going to cause undue solidification of the existing APIs.

> 

> Caveat: I'm not talking about the existing libclang or liblto libraries. Those seem to work and have a small enough API surface that they seem reasonable to support and we can move to a new API if they seem to be hindering development in the future.

> 

> This help explain where I'm coming from here?


So, I'm not opposed to having two levels of stability for LLVM-C APIs. But, if we end up having a separate "stable" and "bindings" API, I think my proposal is basically the level of stability that's needed for a bindings API to be sanely usable. And an actually "stable" API would be expected to have more stability than this: a deprecation policy, at least.

The goal I had is to come up with something that has a minimal cost to ongoing C++ development, while continuing to be useful to users of the LLVM-C API, and further, help to avoid the issue of "we can't add that because it might not be 100% stable".

But, "Anything goes" like the C++ API has, I think is not at all a good idea, as users cannot be guaranteed to get compiler errors to tell them something's changed.


http://reviews.llvm.org/D12685