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
I think it makes sense to officially document this. It has apparently never graduated from being "tribal knowledge". As far as the concrete details, I haven't thought too much, but the deprecation process you suggested makes sense to me. -- Sean Silva On Fri, Jul 17, 2015 at 12:36 PM, Juergen Ributzka <juergen at apple.com> 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. > > 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/20150717/018cc535/attachment.html>
Hi Juergen, Sean, I definitely agree with needing to write down the policy and definitely any policy should include a deprecation time :) Did you want to write up something and let us poke at it? A couple of thoughts outside of a deprecation policy: a) guarantee that the api itself won't go away, but could possibly be turned into a noop? (i.e. source compatibility) b) versioning? (Should we add support for versioning in anyhow? Maybe a C API version 2 to start this off with?) c) One of the big things appears to be the push and pull for "A C API for all C++ entry points" along with "We don't want to get locked into immobility because we have a C API for all C++ entry points". Perhaps part of this might be defining an actual stable set of things along with an unstable set of things? What was the rest of your discussion on this? Any particular points you think the community would be interested in? Just some random thoughts. -eric On Fri, Jul 17, 2015 at 12:54 PM Sean Silva <chisophugis at gmail.com> wrote:> I think it makes sense to officially document this. It has apparently > never graduated from being "tribal knowledge". > > As far as the concrete details, I haven't thought too much, but the > deprecation process you suggested makes sense to me. > > -- Sean Silva > > On Fri, Jul 17, 2015 at 12:36 PM, Juergen Ributzka <juergen at apple.com> > 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. >> >> 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/20150717/fffd11b8/attachment.html>
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.> > Thoughts? Comments? > > Cheers, > Juergen
On Fri, Jul 17, 2015 at 3:33 PM Philip Reames <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" -eric -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150717/034857c2/attachment.html>
Hi Juergen, I've actually got another, perhaps more radical, plan. Let's just get rid of the C API or move it to another project. This simplifies a lot of the plans here where people have too many different ideas of how the C API should work. At this point the people who want a stable C API per incremental version can do that and handle the overhead of porting themselves and the people that want a C API that just happens to be a C interface can have a wrapper (or SWIG or whatever they want). I realize it's radical, but it seems that there are so many different wants for C API here that solving everyone's problems or wants is going to be impossible. -eric On Fri, Jul 17, 2015 at 12:39 PM Juergen Ributzka <juergen at apple.com> 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. > > 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/20150717/45a71b3c/attachment.html>
On 07/17/2015 03:41 PM, Eric Christopher wrote:> Hi Juergen, > > I've actually got another, perhaps more radical, plan. Let's just get > rid of the C API or move it to another project. This simplifies a lot > of the plans here where people have too many different ideas of how > the C API should work. > > At this point the people who want a stable C API per incremental > version can do that and handle the overhead of porting themselves and > the people that want a C API that just happens to be a C interface can > have a wrapper (or SWIG or whatever they want). > > I realize it's radical, but it seems that there are so many different > wants for C API here that solving everyone's problems or wants is > going to be impossible.I really haven't seen that much of a split here honestly. Everyone agrees we need a stable C API for core functionality. The only disagreement seems to be about when something gets promoted to "core" status and even that's been minimal. (I have no opinion w.r.t. your actual proposal.)> > -eric > > On Fri, Jul 17, 2015 at 12:39 PM Juergen Ributzka <juergen at apple.com > <mailto:juergen at apple.com>> 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. > > 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 <mailto:LLVMdev at cs.uiuc.edu> > http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > > > _______________________________________________ > 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/20150717/a513b2bc/attachment.html>
On Fri, Jul 17, 2015 at 3:41 PM, Eric Christopher <echristo at gmail.com> wrote:> Hi Juergen, > > I've actually got another, perhaps more radical, plan. Let's just get rid > of the C API or move it to another project. This simplifies a lot of the > plans here where people have too many different ideas of how the C API > should work. > > At this point the people who want a stable C API per incremental version > can do that and handle the overhead of porting themselves and the people > that want a C API that just happens to be a C interface can have a wrapper > (or SWIG or whatever they want). > > I realize it's radical, but it seems that there are so many different > wants for C API here that solving everyone's problems or wants is going to > be impossible. >I am strongly in favor of moving the bindings, C or otherwise, to another project.> > -eric > > On Fri, Jul 17, 2015 at 12:39 PM Juergen Ributzka <juergen at apple.com> > 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. >> >> 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 >> > > _______________________________________________ > 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/20150717/7acc46a1/attachment.html>
This is interesting. If we did this, the same would apply to the other language bindings, too, yes? We’d end up with a few different mini-projects (or possibly just one w/ a configurable build system). It would also set the stage for, potentially, multiple sets of bindings. As Eric points out, one size doesn’t always fit all, and our current path of trying to find some sort of happy medium may not be the best. This would allow us to have one, or more, binding set which map to different use cases appropriately. So long as we set things up in a way that makes it easy to configure both a unified and discrete (in tree vs. using a “make install” artifact) build, had good bot coverage, etc, etc, I think this could work really well. That said, it’s also a bit of a derail from and most orthogonal to Juergen’s main topic. Perhaps we should split this off to a different thread? -Jim> On Jul 17, 2015, at 3:41 PM, Eric Christopher <echristo at gmail.com> wrote: > > Hi Juergen, > > I've actually got another, perhaps more radical, plan. Let's just get rid of the C API or move it to another project. This simplifies a lot of the plans here where people have too many different ideas of how the C API should work. > > At this point the people who want a stable C API per incremental version can do that and handle the overhead of porting themselves and the people that want a C API that just happens to be a C interface can have a wrapper (or SWIG or whatever they want). > > I realize it's radical, but it seems that there are so many different wants for C API here that solving everyone's problems or wants is going to be impossible. > > -eric > > On Fri, Jul 17, 2015 at 12:39 PM Juergen Ributzka <juergen at apple.com <mailto:juergen at apple.com>> 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. > > 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 <mailto:LLVMdev at cs.uiuc.edu> http://llvm.cs.uiuc.edu <http://llvm.cs.uiuc.edu/> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> > _______________________________________________ > 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/20150717/61b1ab3a/attachment.html>
On Fri, Jul 17, 2015 at 3:41 PM, Eric Christopher <echristo at gmail.com> wrote:> Hi Juergen, > > I've actually got another, perhaps more radical, plan. Let's just get rid > of the C API or move it to another project. This simplifies a lot of the > plans here where people have too many different ideas of how the C API > should work. > > At this point the people who want a stable C API per incremental version > can do that and handle the overhead of porting themselves and the people > that want a C API that just happens to be a C interface can have a wrapper > (or SWIG or whatever they want). > > I realize it's radical, but it seems that there are so many different > wants for C API here that solving everyone's problems or wants is going to > be impossible. >This might backfire if this results in a much better tested interface between the C++ and C API implementation, such that we will actually get red bots when we "break the C API" and be forced to fix it. -- Sean Silva> > -eric > > On Fri, Jul 17, 2015 at 12:39 PM Juergen Ributzka <juergen at apple.com> > 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. >> >> 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 >> > > _______________________________________________ > 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/20150717/d79d736f/attachment.html>
On Sat, 18 Jul 2015 at 03:41 Juergen Ributzka <juergen at apple.com> 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. > > 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. >I think a good first step would be for someone to write tests for the stable API. Once written, these tests must not be changed (excepting bugs in the tests) without going through the deprecation/change process. 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/20150718/b59533a8/attachment.html>
On Fri, Jul 17, 2015 at 10:41:33PM +0000, Eric Christopher wrote:> I've actually got another, perhaps more radical, plan. Let's just get rid > of the C API or move it to another project. This simplifies a lot of the > plans here where people have too many different ideas of how the C API > should work.Wouldn't that just increase the motivation for not caring about the C API at all? "Long absent, soon forgotten." Joerg
+1, I agree with keeping the existing C API stable, and requiring one release of deprecation with an alternative in place to remove something from it. Nobody is going to take the time to design a well-thought out C API that is powerful enough for frontend IRGen and is forward compatible with future versions of LLVM. That's an unsolved problem. We should stick with what we have. The only thing we can do to keep LLVM flexible is to limit the set of new things we expose over the C API boundary, which I'm totally in favor of. On Fri, Jul 17, 2015 at 12:36 PM, Juergen Ributzka <juergen at apple.com> 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. > > 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/20150730/7336af21/attachment.html>
I think the idea of having a (hopefully not too) fluid C API that can encompass everything people want to be able to do in the language of their choice and calls into LLVM to do work sounds like a great idea. I think it would be useful to expand the number of people who are able to do research and development with LLVM without having to reinvent LLVM. That said, this is directly at odds with our desire to have a stable C API that can be supported long term (as you said at the end of the email). I.e. where do we draw the line on what can or should be added to the C API? What if the people that want the functionality are willing to deal with it being (occasionally) unstable? I don't agree with you that no one will take the time to design a well thought out C API. We've managed to get a lot of real world experience lately at both how these things will be used, and how we'll maintain such a thing. I think Juergen and others are a good group to come up with an answer to our engineering challenge. -eric On Thu, Jul 30, 2015 at 11:54 AM Reid Kleckner <rnk at google.com> wrote:> +1, I agree with keeping the existing C API stable, and requiring one > release of deprecation with an alternative in place to remove something > from it. > > Nobody is going to take the time to design a well-thought out C API that > is powerful enough for frontend IRGen and is forward compatible with future > versions of LLVM. That's an unsolved problem. We should stick with what we > have. > > The only thing we can do to keep LLVM flexible is to limit the set of new > things we expose over the C API boundary, which I'm totally in favor of. > > On Fri, Jul 17, 2015 at 12:36 PM, Juergen Ributzka <juergen at apple.com> > 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. >> >> 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 >> > > _______________________________________________ > 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/20150730/8692fb81/attachment.html>
deadal nix via llvm-dev
2015-Aug-17 01:45 UTC
[llvm-dev] [LLVMdev] [RFC] Developer Policy for LLVM C API
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>
Eric Christopher via llvm-dev
2015-Aug-17 04:47 UTC
[llvm-dev] [LLVMdev] [RFC] Developer Policy for LLVM C API
On Sun, Aug 16, 2015 at 6:45 PM deadal nix via llvm-dev < llvm-dev at lists.llvm.org> wrote:> 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. > >Right, and that's the problem. Expanding the C API to cover reading and generating IR in a stable way will lock the C++ API down in a way that I'm not comfortable with - I think it has already gone too far. -eric> 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 >> > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org http://llvm.cs.uiuc.edu > 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/20150817/5cbdf3c4/attachment-0001.html>