[llvm-dev] A Short Policy Proposal Regarding Host Compilers

[Chandler Carruth via llvm-dev]

On Thu, Jan 10, 2019 at 4:36 PM Mehdi AMINI via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
>
> On Thu, Jan 10, 2019 at 4:32 PM JF Bastien <jfbastien at apple.com> wrote:
>
>>
>>
>> On Jan 10, 2019, at 4:30 PM, Mehdi AMINI <joker.eph at gmail.com> wrote:
>>
>> I'm a bit puzzled as of why would a fix period of time be the best option
>> to automatically cut support for older compilers?
>>
>> Historically I believe we've been looking at a combination of:
>>
>> 1) What new feature we gain by dropping support for a given version of
>> the compiler
>> 2) What major OS out there have available (possibly through PPA?).
>>
>> And balance the two aspects.
>>
>> What is the motivation for changing this approach?
>>
>>
>> Historically we’ve been on C++11, minus some stuff. The motivation to
>> change the approach is to not be stuck on older C++ versions.
>>
>
> I don't understand why migrating to c++14 has anything to do with changing
> the approach.
> We migrated to C++11 using the framework I mentioned above, I don't see
> why we can't do it for C++14?
>
> I'm afraid that a fix number of year is purely arbitrary and does not
> serve the best interest of the users. The only "pro" I perceive is avoiding
> the work of discussing the tradeoff when dropping support for an old
> version of one of the supporter host toolchain, and making our life easier
> on this seems superficial to me.
>

I think a fixed number of years is a good basis to *remind* us to look and
see whether it would be useful to push things up. IE, we should at least
check periodically.

I think it also gives a useful baseline expectation to users and downstream
folks about the rough rate of such changes to be expected.

But I agree with you that we shouldn't hold these timeframes as fixed or
hard constraints. I just still see value with having them so that we're not
just random in when we consider updating.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190110/817d1a3d/attachment.html>