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

[David Chisnall via llvm-dev]

On 23/07/2020 16:28, Nicolai Hähnle via llvm-dev wrote:
> I'm generally on board with this, certainly between LLVM releases, but
> I feel like it would be friendlier to use (potentially short-lived)
> deprecation as a tool for LLVM trunk.
> 
> We maintain an out-of-tree compiler[0] and try to be good citizens by
> following LLVM trunk very closely. It is always frustrating when a
> very central part of LLVM (like the Builders, or Instructions) have a
> "flag-day" change, where our frontend must be changed in a way where
> the new version doesn't work with LLVM trunk that is even a few days
> old, and the old version doesn't work with current LLVM trunk.
> 
> In many, many cases it is almost zero effort for the person making the
> chance in LLVM to split it up into a sequence of logical changes:
> 
> 1) Add the new API.
> 2) Use it in llvm-project.
> 3) Add LLVM_ATTRIBUTE_DEPRECATED to the old API.
> 4) Remove the old API.
> 
> 1-3 could be in a single commit, but having a few weeks between them
> and point 4 helps_massively_.
> 
> It allows us to keep compiling against LLVM trunk in our CI, while one
> person goes and fixes up our use of the API (which we can detect
> automatically thanks to the warning or -Werror). It also makes it
> easier for us to bisect regressions across such API changes.
> 
> With the alternative, where 1-4 are all in a single commit, our
> integration with LLVM trunk is blocked until somebody can fix it --
> which is usually as quick as 1 or 2 days, but during that time window
> we don't catch any_other_  regressions in LLVM trunk that might affect
> us.
> 
> So please, let's make it a common rule to use this two-step,
> transactional approach to changes in APIs that are relatively "core"
> (which mostly means llvm/IR, llvm/ADT, llvm/Support, perhaps with a
> side of llvm/Analysis). I am perfectly fine with this rule being
> broken occasionally, for changes where it would be exceedingly tricky
> to do them in a non-flag-day way. But in our experience, most of the
> changes that would actually affect an out-of-tree frontend aren't this
> tricky.

I agree that deprecation is much more friendly but the last time I 
proposed it there was a lot of push-back.  Given this thread is about 
documenting the existing policy, rather than changing the policy, I I'd 
recommend starting a new RFC thread about deprecation.

David