<div dir="ltr"><div dir="ltr">On Thu, Jan 10, 2019 at 4:36 PM Mehdi AMINI via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jan 10, 2019 at 4:32 PM JF Bastien <<a href="mailto:jfbastien@apple.com" target="_blank">jfbastien@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;"><br><div><br><blockquote type="cite"><div>On Jan 10, 2019, at 4:30 PM, Mehdi AMINI <<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>> wrote:</div><br class="gmail-m_-4424292047243162759gmail-m_5931519459199768432Apple-interchange-newline"><div><div dir="ltr"><div>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?</div><div><br></div><div>Historically I believe we've been looking at a combination of:</div><div><br></div><div>1) What new feature we gain by dropping support for a given version of the compiler</div><div>2) What major OS out there have available (possibly through PPA?).</div><div><br></div><div>And balance the two aspects.</div><div><br></div><div>What is the motivation for changing this approach?</div></div></div></blockquote><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>I don't understand why migrating to c++14 has anything to do with changing the approach. </div><div>We migrated to C++11 using the framework I mentioned above, I don't see why we can't do it for C++14?</div><div><br></div><div>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.</div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>I think it also gives a useful baseline expectation to users and downstream folks about the rough rate of such changes to be expected.</div><div><br></div><div>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.</div><div><br></div><div>-Chandler</div></div></div>