<div dir="ltr">Given that no policy existed before the adoption of it should include a grace period. So it should read:<div><br></div><div><div style="font-size:12.8px">* Starting with clang 7 we can bump the minimum required non-Microsoft toolchain version every 4 years.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-11-01 14:24 GMT-02:00 Zachary Turner via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><span><div dir="ltr">On Tue, Oct 31, 2017 at 11:23 PM Zachary Turner <<a href="mailto:zturner@google.com" target="_blank">zturner@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I’m ok with that, but the reason I’m pushing is because there is no clear plan of action.  Even if the plan of action is “When X happens, we can enable C++14”, that’s fine too.  I just want to know, concretely, what is X.<br><br>We should either be able to say never or give a reasonable set of conditions that would enable a switch.  All I’ve seen though is “it’s hard” which just means I’m going to ask again next year, and the year after, etc due to lack of clear guidance.<br><br>To address your point though , this isn’t really about building everything with clang.  You don’t need to bootstrap Clang to build a hypothetical C++17 enabled LLVM, you could also bootstrap a more modern version of GCC.<br><br>This is really more fundamentally about “Can we have a clearly defined policy about how often we can bump the minimum compiler version, like we have for MSVC?” </blockquote><div><br></div></span><div>To make this even more concrete, let me offer a proposal:</div><div><br></div><div>* We can bump the minimum required non-Microsoft toolchain version every 4 years.</div><div><br></div><div>Having something written like this allows us to have a schedule, and having a schedule allows downstream consumers to plan upgrades as needed so as to minimize disruption.</div><div><br></div><div>4 years is also a pretty reasonable amount of time IMO, but we can certainly discuss the exact value of N.</div><div><br></div><div>I haven't said anything here about what it can be bumped *to*.  But in the interest of making progress, I'm separating the decisions out into smaller pieces so we can focus on one thing at a time.</div></div></div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div></div>