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

[James Y Knight via llvm-dev]

On Mon, Aug 17, 2015 at 3:46 PM, Daniel Berlin <dberlin at dberlin.org> wrote:

> 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?
>

Okay, kinda? I mean, more testing is always good. If you're missing a test,
and then break something by accident, well, that sucks. But, the important
first step is to agree that the *policy* is to not change the C API in that
way. If something like that does happen, treat it as a bug to be
(hopefully) fixed, rather than something that's allowed by the development
policy so "oh well".

With the way the C API is currently defined, maintaining that property
actually seems like it's pretty straightforward, because all the types it
uses are defined in the C API headers. So, basically: be careful about how
you change the C API headers. Which people already are being.

Maybe I shouldn't have said "100% strict" -- I didn't actually mean "the
world will explode if we get this wrong and introduce a bug" -- it
certainly won't. It would just be inconvenient, so have a policy of not
doing it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150817/692e58a9/attachment.html>