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

[Eric Christopher]

Hi Juergen,

I've actually got another, perhaps more radical, plan. Let's just get rid
of the C API or move it to another project. This simplifies a lot of the
plans here where people have too many different ideas of how the C API
should work.

At this point the people who want a stable C API per incremental version
can do that and handle the overhead of porting themselves and the people
that want a C API that just happens to be a C interface can have a wrapper
(or SWIG or whatever they want).

I realize it's radical, but it seems that there are so many different wants
for C API here that solving everyone's problems or wants is going to be
impossible.

-eric

On Fri, Jul 17, 2015 at 12:39 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/20150717/45a71b3c/attachment.html>