<div dir="ltr">On 6 November 2013 10:15,  <span dir="ltr"><<a href="mailto:dag@cray.com" target="_blank">dag@cray.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><span style="color:rgb(34,34,34)">No.  We need to know which version of the tools to test.  As far as I</span><br></div>
know, a specific version (point release) hasn't been chosen yet.<br>
<br>
A toolchain upgrade is a *major* issue for large software projects.  I'm<br>
all for C++-11.  It's long past due that we use it in LLVM.  However,<br>
prudence dictates that we allow enough time for testing before swapping<br>
toolchains out from under people.<br></blockquote><div></div></div><br></div><div class="gmail_extra">Davids,</div><div class="gmail_extra"><br></div><div class="gmail_extra">I think there are two main problems here:</div>
<div class="gmail_extra"> 1. People use trunk on side-projects because releases mean very little in LLVM world</div><div class="gmail_extra"> 2. We start adding new stuff as soon as a release is branched, and that reduces warnings up to a few days</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">We're all talking about problem 2, when in fact, I think the problem is in 1.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I personally don't think it's feasible to base a product/project on a moving target. You already have your code that is moving, having its base moving too is asking for trouble. This is the same as upgrading the GCC from 4.8 to 4.9 when it comes out on a major distro just because it's shiny.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Why do we do it, then? Because LLVM releases mean very little, and the only meaningful branch is trunk. This, for me, is the real problem. There was a thread a while ago talking about backports for stable releases, and it has been discussed in the Linaro Connect and other satellite meetings that, if we want to use LLVM as a platform compiler to whatever project/distro we *must* maintain old releases. After all, GCC doesn't do that just because it's fun (believe me, it's not!).</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">But now that we've come all the way trying to introduce a huge change and hit this wall, what would the solution be? Are we going to press hard and make the change? I don't think it's a good idea. As much as I want to see C++11 and beyond in LLVM, I don't want to destroy one of its biggest strength: its community.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">However, Tim's position is important to consider: we've been talking about this for a long while, but because no one actually set the date, packagers and side projects just ignored as a problem 'to deal later, when it really happens'. So, as much as I understand the work that needs to be done by the side projects, there has been a lot of warning for almost a year (if not more). Still, I don't think that an issue like that can be forced down just because there were discussions on the list, we need a proper schedule.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">If we end up with a decent release policy (for backports, bugfixes, critical performance improvements), side projects and distributions would be able to use that as a base and let trunk be wild and crazy, as it's meant to be.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Makes sense?</div><div class="gmail_extra"><br></div><div class="gmail_extra">cheers,</div><div class="gmail_extra">--renato</div></div>