<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 7, 2013 at 9:04 AM,  <span dir="ltr"><<a href="mailto:dag@cray.com" target="_blank" class="cremed">dag@cray.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">Renato Golin <<a href="mailto:renato.golin@linaro.org" class="cremed">renato.golin@linaro.org</a>> writes:<br>
<br>
> In a nutshell, if we want the toolchain to evolve with time, we'll<br>
> need to have API changes, and we'll need to update surrounding<br>
> software to cope with that. The only difference is if we want to be<br>
> doing this as our day-to-day job, or twice a year (or even less than<br>
> that if you stay on a release for a while longer). I personally think<br>
> that it's more manageable to do that on releases than on trunk (been<br>
> there, done that, and it sucks).<br>
<br>
</div>Except that the core developers recommend working off trunk.  If you<br>
want to contribute code back, you pretty much have to work off trunk.<br></blockquote><div><br></div><div>The need to base your work off of trunk to contribute it back is an inherent fact of life with a project that moves as fast as LLVM. No amount of stable APIs would remove this pressure.</div>
<div><br></div><div>This does (naturally) come with a cost. Chasing API changes is easily the most impactful thing we deal with here, and I suspect it is for others as well. It still is less expensive (IMO) than doing one-off updates from release X to release X+N. And it still dwarfs the cost of using a reasonably modern toolchain.</div>
</div></div></div>