[llvm] r255300 - Add C API guidelines to the developer policy to match discussions

Eric Christopher via llvm-commits llvm-commits at lists.llvm.org
Thu Dec 10 13:33:53 PST 2015


Author: echristo
Date: Thu Dec 10 15:33:53 2015
New Revision: 255300

URL: http://llvm.org/viewvc/llvm-project?rev=255300&view=rev
Log:
Add C API guidelines to the developer policy to match discussions
on the llvm mailing lists.

Modified:
    llvm/trunk/docs/DeveloperPolicy.rst

Modified: llvm/trunk/docs/DeveloperPolicy.rst
URL: http://llvm.org/viewvc/llvm-project/llvm/trunk/docs/DeveloperPolicy.rst?rev=255300&r1=255299&r2=255300&view=diff
==============================================================================
--- llvm/trunk/docs/DeveloperPolicy.rst (original)
+++ llvm/trunk/docs/DeveloperPolicy.rst Thu Dec 10 15:33:53 2015
@@ -525,6 +525,33 @@ for llvm users and not imposing a big bu
   it is to drop it. That is not very user friendly and a bit more effort is
   expected, but no promises are made.
 
+C API Changes
+----------------
+
+* Stability Guarantees: The C API is, in general, a “best effort” for stability.
+This means that we make every attempt to keep the C API stable, but that
+stability will be limited by the abstractness of the interface and the stability
+of the C++ API that it wraps. In practice, this means that things like “create
+debug info” or “create this type of instruction” are likely to be less stable
+than “take this IR file and JIT it for my current machine”.
+
+* Release stability: We won’t break the C API on the release branch with patches
+that go on that branch, with the exception that if we will fix an unintentional
+C API break that will keep the release consistent with both the previous and next
+release.
+
+* Testing: Patches to the C API are expected to come with tests just like any
+other patch.
+
+* Including new things into the API: If an LLVM subcomponent has a C API already
+included, then expanding that C API is acceptable. Adding C API for subcomponents
+that don't currently have one is fine, and the details of how best to design that
+API should be discussed on the mailing list.
+
+* Documentation: Any changes to the C API are required to be documented in the
+release notes so that it’s clear to external users who do not follow the project
+how the C API is changing and evolving.
+
 .. _copyright-license-patents:
 
 Copyright, License, and Patents




More information about the llvm-commits mailing list