[llvm-dev] Explicitly spelling out the lack of stability for the C++ API in the Developer Policy?

Chris Lattner via llvm-dev llvm-dev at lists.llvm.org
Sun Jul 26 14:40:17 PDT 2020


On Jul 24, 2020, at 9:50 AM, Mehdi AMINI via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> Besides, I think you misunderstood: the point isn't to *forbid*
> flag-day changes. The point is to encourage thinking about how to do
> refactoring better. Sometimes a flag-day change is required, and
> that's fine, but in the vast majority of cases it isn't.
> 
> No I perfectly understood, I'm still not in favor of codifying an encouragement in this direction: I'm not eager to have reviewers ask me to change my patch to follow the scheme you describe for stability purposes.

I can see both sides of this.  Deprecation has a lot of value that Nicolai points out and some people do use it.  I don’t think it is possible to get to perfect “deprecation cycles” and even outside perfection an overly-broad application of this would just be expensive.  Some things (e.g. core IR) simply matter more than others.

Perhaps a way too slice this is to phrase it along the lines of:

1) There is no guarantee.
2) That said, for core IR changes it is nice to stage them for XYZ reasons.
3) If you do so, “this is the right way".

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200726/b9256d8a/attachment.html>


More information about the llvm-dev mailing list