[llvm-dev] [LLVMdev] [RFC] Developer Policy for LLVM C API

[Daniel Berlin via llvm-dev]

On Mon, Aug 17, 2015 at 12:31 PM, James Y Knight via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> I'd propose that the only 100% strict rule should be that if the ABI/API
> changes, it is done in a way that *loudly* breaks old programs -- e.g. they
> fail to compile, link, or run (depending on how the other-lang wrappers are
> accessing the API functions) -- not that you get some random weird
> misbehavior because a function's argument types or return type has been
> changed.


This would require a level of testing that we don't have, just to make
sure that happens, no?

>
> Ideally, if you're going to remove an API, you'd deprecate it first, if you
> can see the problem coming. Otherwise, oh well -- it's not reasonable to
> hold up LLVM development to adhere to deprecation policy on the C API.
>
> That is:
> 1) Adding new functions for new LLVM functionality: great.
> 2) Removing old functions: if it's required -- after careful deliberation.
> 3) Modifying the signature of existing functions: no way.
>
> A couple of concrete examples:
>
> - Let's say you run out of space in an existing enum type (ahem,
> LLVMAttribute...).
>
> You should introduce new function names, taking a better type (perhaps some
> sort of set type, instead of a fixed-width integer...), mark the old ones
> deprecated so that users will update to the new functions. But, keep the old
> ones around so that old code can keep working. There's no real need to
> remove the old deprecated functions -- they'll keep working as well as they
> ever did with the smaller-valued attributes.

Maybe?
Maybe not?
Maybe they were broken when built.