<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Nov 6, 2013 at 1:07 AM, David Chisnall <span dir="ltr"><<a href="mailto:David.Chisnall@cl.cam.ac.uk" target="_blank" class="cremed">David.Chisnall@cl.cam.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":7wj" style="overflow:hidden">I think his point was that we encourage out-of-tree projects to follow ToT[1] and so announcing in x.y that x.(y+1) will use C++11 (or C++14) feature Z means that people may start using that feature in ToT as soon as the x.y release is branched (which may be even before the announcement that x.(y+1) will use the new feature).<br>
</div></blockquote><div><br></div><div>So, this email discussion, and the summary email I sent to the dev lists is the announcement. So there will be some time for folks to do this. I think *no* warning is too little warning, but I don't think that's what we're talking about here.</div>
<div><br></div><div>That said, I completely agree that this is a relatively aggressive schedule for ToT. I also like that you draw analogy to the API changes which I view is quite similar.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div id=":7wj" style="overflow:hidden">
<br>
If the new feature requires out-of-tree LLVM users to upgrade their toolchains then we may only be giving them a month or less warning, even if we are giving downstream packagers 6 months.<br>
<br>
Given how hard we already make it for people to follow ToT for out-of-tree projects (and how much we shout at them when they don't), I'd rather that we didn't make it any harder.<br></div></blockquote><div><br>
</div><div>I actually am not sure about the shouting at people when they don't follow ToT with their out-of-tree projects.</div><div><br></div><div>I see a lot more pressure for folks to do their work in the open than to do closed source work against ToT. I think that's actually reasonably healthy for the project. The (very significant) overhead of tracking ToT or even release-to-release changes (and the workarounds for the bugs that never get a patch release) tend to heavily incentivize people to contribute back their changes. One of the primary benefits of pushing changes back into the open source repo is that now API updates are done for you.</div>
<div><br></div><div>So, *if* you need to maintain an out of tree project (and there are a bunch of really good reasons to do this!), you end up paying a steep tax to track *either* ToT or each release.</div><div><br></div>
<div>In the case of tracking ToT, I think that the cost of dealing with API changes is tremendously higher than switching to a C++11 supporting toolchain. (Of course, in aggregate. Each API change may be cheaper, but they come in such frequency that the total cost seems likely to dwarf that of the toolchain rev.)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":7wj" style="overflow:hidden">
<br>
And with my downstream packager hat on, it's frustrating that we don't make it easier, because we end up having to make sure that it's possible to install half a dozen different versions of LLVM simultaneously because there are always some projects that depend on an old one and only have the manpower to handle the API churn every few releases - I think we've now finally got rid of the ones that depend on LLVM 2.6, but 2.8 is still quite popular.<br>
</div></blockquote><div><br></div><div>Again, I think the API issues are far and away the dominant concerns here. I'm not trying to say your concern is invalid; while I would pick a different tradeoff, its still at most a tradeoff and reasonable people can disagree about the right tradeoff to make. However, even from this perspective, I feel like the cost and tradeoffs you face with APIs dwarf those you face with us starting to use C++11. It seems like if this is what we should be optimizing for, we should start by fixing the API churn issue and then look at other sources of churn. However, thus far the project has chosen *not* to optimize for this, and instead to optimize for in-tree efforts. Using C++11 seems like icing on this cake.</div>
<div><br></div><div>-Chandler</div></div></div></div>