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

[Nicolai Hähnle via llvm-dev]

On Sun, Jul 26, 2020 at 11:40 PM Chris Lattner <clattner at nondot.org> wrote:
>
> 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".

That sounds good to me.

Cheers,
Nicolai


>
> -Chris



-- 
Lerne, wie die Welt wirklich ist,
aber vergiss niemals, wie sie sein sollte.