llvm dev - May 2016 - LLVM Releases: Upstream vs. Downstream / Distros

On 12 May 2016 at 16:56, Kristof Beyls <Kristof.Beyls at arm.com> wrote:
> In my opinion, it would be better overall for the LLVM project if
> top-of-trunk is
> tested as much as possible, if testing resources are so scarce that a
> choice
> has to be made between testing top-of-trunk or testing a release branch.
>
I agree that trunk is more important, with both of my hats on.

But releases are not completely irrelevant - one thing making them
important is the fact that there's other projects out there using the LLVM
libraries - and as a distro, we have to make sure they all work (so they
agree on the same API), preferably without having to ship multiple versions
of LLVM and preferably without having to patch external code too much to
adjust to API changes.

In OpenMandriva, we have to keep Mesa, creduce, emscripten and the
LLVMified Qt moc working (list expected to grow -- ultimately we'd also
like to use the system LLVM libraries for the swift compiler).
In AOSP, RenderScript relies on the LLVM API, but there's nothing else
using it, so there's currently no need to force a common version of the API
between different projects there.

ttyl
bero
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160512/05590a18/attachment.html>

On Thu, 12 May 2016 16:40:44 +0100
David Chisnall via cfe-dev
<cfe-dev at lists.llvm.org> wrote:
> 
> The end result is that shortly after a release (sometimes every alternate
release) is branched a load of downstream projects update to the new APIs, test
things, and find a bunch of regressions that have been sitting in the tree for
months.  We then have to scrabble to bisect and try to track them down.
> 
> TL;DR version: If we want downstream people to test ToT, then we need to
make updating LLVM library consumers to ToT far less painful than it is now.
+1 to this.  As a developer of llvmlite and numba, it would be
counter-productive for me to try to follow the LLVM ToT, as opposed to
migrate after a X.Y.1 release as we currently do.

Regards

Antoine.