[LLVMdev] [RFC] Developer Policy for LLVM C API (original) (raw)

Philip Reames listmail at philipreames.com
Fri Jul 17 16:16:17 PDT 2015

On 07/17/2015 03:35 PM, Eric Christopher wrote:

On Fri, Jul 17, 2015 at 3:33 PM Philip Reames <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:

On 07/17/2015 12:36 PM, Juergen Ributzka 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. +1 > > 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. +1 I'd suggest we also have an officially unofficial policy about not versioning just for style or cleanliness reasons. i.e. We should try to minimize churn of the API unless it's actually needed, or supporting an old API becomes unjustifiably complicated. Could you explain what you mean here? As far as I can tell this is "I don't want versioning unless I want versioning and then I'll want it because it's convenient for me" What I was trying to get at is that we should aim to not change the API unless it's actually needed. Just because we have a versioning mechanism doesn't mean we should freely make use of it. Some examples:

We tend to be much more free with the C++ APIs (with good cause). I don't want to see this applied to the C API. We should still seek to keep a stable API even if we do have a formal mechanism for revising it.

p.s. If that sounds obvious, you've read it right. :) This wasn't intended to be controversial, just to cement in writing the attitude we've already taken.

p.p.s. The preceding would only apply to the "stable" parts of the API.

Philip

-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150717/4ee6ea14/attachment.html>

More information about the llvm-dev mailing list