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

[Philip Reames]

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:
- Renaming a method in the API - bad
- Dropping a method involving functionality no longer supported - good

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>