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

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

>> 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.
If we decide to delay this yet again (it's been on the cards since
January, so I'm personally opposed, but still...) we should at least
start counting the "acceptable notice" from the start of this thread
rather than when the dust settles.

Cheers.

Tim

On 11/ 7/13 12:27 AM, Tim Northover wrote:
>>> 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.
> If we decide to delay this yet again (it's been on the cards since
> January, so I'm personally opposed, but still...) we should at least
> start counting the "acceptable notice" from the start of this
thread
> rather than when the dust settles.
because a discussion starts - and the Tea party wants their way.. it 
doesn't mean it's final. I'd love to ignore this thread until
something
is actually announced... with "proper" notice..

// I still don't get the fire everyone is trying to put out...

Tim Northover <t.p.northover at gmail.com> writes:
>>> 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.
>
> If we decide to delay this yet again (it's been on the cards since
> January, so I'm personally opposed, but still...) we should at least
> start counting the "acceptable notice" from the start of this
thread
> rather than when the dust settles.
No.  We need to know which version of the tools to test.  As far as I
know, a specific version (point release) hasn't been chosen yet.

A toolchain upgrade is a *major* issue for large software projects.  I'm
all for C++-11.  It's long past due that we use it in LLVM.  However,
prudence dictates that we allow enough time for testing before swapping
toolchains out from under people.

                            -David