[LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

[dag at cray.com]

David Chisnall <David.Chisnall at cl.cam.ac.uk> writes:

>> I may be wrong, but I think the final consensus was: for every new
>> change, warn on (at least) one previous release as when the changes
>> go live.
>> 
>> If I'm mistaken, this is still my opinion on the matter.
>
> I think his point was that we encourage out-of-tree projects to follow
> ToT[1] and so announcing in x.y that x.(y+1) will use C++11 (or C++14)
> feature Z means that people may start using that feature in ToT as
> soon as the x.y release is branched (which may be even before the
> announcement that x.(y+1) will use the new feature).

Yep.

> If the new feature requires out-of-tree LLVM users to upgrade their
> toolchains then we may only be giving them a month or less warning,
> even if we are giving downstream packagers 6 months.

Correct.  That's not enough warning.

> Given how hard we already make it for people to follow ToT for
> out-of-tree projects (and how much we shout at them when they don't),
> I'd rather that we didn't make it any harder.
>
> And with my downstream packager hat on, it's frustrating that we don't
> make it easier, because we end up having to make sure that it's
> possible to install half a dozen different versions of LLVM
> simultaneously because there are always some projects that depend on
> an old one and only have the manpower to handle the API churn every
> few releases - I think we've now finally got rid of the ones that
> depend on LLVM 2.6, but 2.8 is still quite popular.

Thank you for that.  You've summarize all of the issues with the current
development and release practice quite well.

> David
>
> [1] We make their life very hard by introducing new APIs long before
> we document them. For example, we still don't have adequate
> documentation of the new attributes classes, but that's a separate
> rant.

Yes!

                           -David