[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