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

On Aug 18, 2015, at 10:41 PM, deadal nix <deadalnix at gmail.com>
wrote:
> Let's not get this die. The C API is too valuable to let this die.
> 
> I propose the following plan:
>  - Add tests for the current API. This will allow to make sure that
everything works and would ensure that changes are made intentionally, nto
accidentally.
>  - For area that do not exist in the C API right now, and for which support
seems needed, we establish a plan to support it according to current
functionality and planned evolution.
>  - It is understood that the C API require more stability than the C++ one
as it is often used accross language boundary where type checking cannot be
done. On the other hand, no promise of stability is made so LLVM can still
evolve at "ludicrous speed". If a change to LLVM cannot be mapped to
the current API, the API is updated.
+1 from me, with the additional "no changing existing functions'
signatures, replace with new function if necessary" rule.

Perhaps you can make a patch to the DeveloperPolicy document actually writing
down your view on the Developer Policy for the C API? Then we never have to
debate it again, because it'll be written down for future reference. And,
reviewing that patch will give people one last opportunity to object and/or
bikeshed. :)

James

BTW for those following along, I wrote up a concrete proposal saying
basically that, at http://reviews.llvm.org/D12685, if anyone else was
interested in providing their input.

So far it's garnered a -1 from Eric.

On Thu, Aug 27, 2015 at 7:34 PM, James Y Knight <jyknight at google.com>
wrote:
> On Aug 18, 2015, at 10:41 PM, deadal nix <deadalnix at gmail.com>
wrote:
> > Let's not get this die. The C API is too valuable to let this die.
> >
> > I propose the following plan:
> >  - Add tests for the current API. This will allow to make sure that
> everything works and would ensure that changes are made intentionally, nto
> accidentally.
> >  - For area that do not exist in the C API right now, and for which
> support seems needed, we establish a plan to support it according to
> current functionality and planned evolution.
> >  - It is understood that the C API require more stability than the C++
> one as it is often used accross language boundary where type checking
> cannot be done. On the other hand, no promise of stability is made so LLVM
> can still evolve at "ludicrous speed". If a change to LLVM cannot
be mapped
> to the current API, the API is updated.
>
> +1 from me, with the additional "no changing existing functions'
> signatures, replace with new function if necessary" rule.
>
> Perhaps you can make a patch to the DeveloperPolicy document actually
> writing down your view on the Developer Policy for the C API? Then we never
> have to debate it again, because it'll be written down for future
> reference. And, reviewing that patch will give people one last opportunity
> to object and/or bikeshed. :)
>
> James
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150915/eb62b89d/attachment.html>

Just in case it wasn't said, I do want to thank you for sending out a
concrete proposal here, I really appreciate it. It's good to have more
proposals as direction.

I'm not sure what else I can say that I haven't as far as in this thread
as
a proposal, I can resend it out with a migration plan if that helps?

-eric

On Tue, Sep 15, 2015 at 9:20 AM James Y Knight via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> BTW for those following along, I wrote up a concrete proposal saying
> basically that, at http://reviews.llvm.org/D12685, if anyone else was
> interested in providing their input.
>
> So far it's garnered a -1 from Eric.
>
> On Thu, Aug 27, 2015 at 7:34 PM, James Y Knight <jyknight at
google.com>
> wrote:
>
>> On Aug 18, 2015, at 10:41 PM, deadal nix <deadalnix at gmail.com>
wrote:
>> > Let's not get this die. The C API is too valuable to let this
die.
>> >
>> > I propose the following plan:
>> >  - Add tests for the current API. This will allow to make sure
that
>> everything works and would ensure that changes are made intentionally,
nto
>> accidentally.
>> >  - For area that do not exist in the C API right now, and for
which
>> support seems needed, we establish a plan to support it according to
>> current functionality and planned evolution.
>> >  - It is understood that the C API require more stability than the
C++
>> one as it is often used accross language boundary where type checking
>> cannot be done. On the other hand, no promise of stability is made so
LLVM
>> can still evolve at "ludicrous speed". If a change to LLVM
cannot be mapped
>> to the current API, the API is updated.
>>
>> +1 from me, with the additional "no changing existing
functions'
>> signatures, replace with new function if necessary" rule.
>>
>> Perhaps you can make a patch to the DeveloperPolicy document actually
>> writing down your view on the Developer Policy for the C API? Then we
never
>> have to debate it again, because it'll be written down for future
>> reference. And, reviewing that patch will give people one last
opportunity
>> to object and/or bikeshed. :)
>>
>> James
>>
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150915/24bd324e/attachment.html>