[LLVMdev] [RFC] Developer Policy for LLVM C API

[Reid Kleckner]

+1, I agree with keeping the existing C API stable, and requiring one
release of deprecation with an alternative in place to remove something
from it.

Nobody is going to take the time to design a well-thought out C API that is
powerful enough for frontend IRGen and is forward compatible with future
versions of LLVM. That's an unsolved problem. We should stick with what we
have.

The only thing we can do to keep LLVM flexible is to limit the set of new
things we expose over the C API boundary, which I'm totally in favor of.

On Fri, Jul 17, 2015 at 12:36 PM, Juergen Ributzka <juergen at apple.com>
wrote:

> Hi @ll,
>
> a few of us had recently a discussion about how to manage the C API and
> possible policies regarding addition, maintenance, deprecation, and removal
> of API.
>
> Even thought there is a strong agreement in the community that we
> shouldn't break released C API and should be backwards compatible, there
> doesn’t seem to be a developer policy that backs that up. This is something
> we should fix.
>
> I was wondering what the interested parties think of the current approach
> and what could/should we improve to make the use and maintenance of the C
> API easier for users and the developers alike.
>
> I was hoping we could also introduce a process that allows the removal of
> an API after it has been deprecated for a whole release and the release
> notes stated that it will be removed.
>
> Thoughts? Comments?
>
> Cheers,
> Juergen
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150730/7336af21/attachment.html>