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

[deadal nix via llvm-dev]

Chiming in with http://reviews.llvm.org/D10725

Being able to read and generate IR is at least some very basic thing we can
agree on is needed. Can we get some testing for it ? Personally I don't
really mind if this is going to be stable or not, but at least, having some
test coverage would allow to take whatever path that is going to be taken
willingly.

I'd like also to remind all to not fall into the hypothetical nirvana
fallacy, ie comparing proposed solution with an idealized and unrealized
one. That's a good recipe for endless bikescheding when pretty much
anythign would be better than the status quo.

2015-07-17 12:36 GMT-07:00 Juergen Ributzka <juergen at apple.com>:

> 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/20150816/40cbdc99/attachment.html>