<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Focusing on one comment:</div><div class="gmail_quote"><br></div><div class="gmail_quote">On Mon, Oct 28, 2013 at 3:12 PM, Brooks Davis <span dir="ltr"><<a href="mailto:brooks@freebsd.org" target="_blank" class="cremed">brooks@freebsd.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":3qy" style="overflow:hidden">Today you could probably pick a somewhat newer<br>
Clang than 3.1 without much real impact on us, but it would hurt to have<br>
the requirements change with every release.  From our perspective it's<br>
much better to change no more than every two years or so.</div></blockquote></div><br>I think that from the project's perspective, we will have much better success if we at least evaluate this after each release. That's the time cycle on which we will have a reason to think about it.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I don't think that it makes sense to only change every two years. If you want more stability, I think the easy path to that is to jump Clang versions, say, every year. Then you'll control and slow down the upgrade frequency on your end, but there will always be enough overlap with the latest release.</div>
</div>