[llvm-dev] Should I worry about test failures in a release?

[Renato Golin via llvm-dev]

On 13 October 2015 at 09:19, Joachim Durchholz via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Oh... why do I need to rebase?

If your project is a product that wants to benefit from the advances
of LLVM over the years, you'll have to update the code to the newer
versions some time. Moreover, if you do find a bug, and it's in an old
version, you won't have the same response times than if it's in trunk.
Very likely, you'll get no response at all. As I said earlier, our
releases are "stable points in time", not final products that have
support contracts.


> I don't have the manpower or C++ expertise to hack on LLVM itself, I've been
> planning to just use it. Since I'm just doing a proof of concept, I
> (hopefully) won't have to use any of the more experimental stuff.

Right, so sticking to the 3.7.0 release is probably your best bet.
It's feature complete on most targets (x86, ARM, MIPS, PPC), 32-bit
and 64-bit. You should be fine with that for a while.


> A different but related questons: Are minor releases of LLVM
> backwards-compatible?

Both ABI and API compatible. You should be safe migrating from 3.7.0
to .1 or .2 without a single change on your part. If there are any,
please report as a bug.


> Bitcode compatibility would be particularly
> interesting - can I assume that the LLVM toolchain is able to work with
> bitcode generated by earlier versions of the toolchain?

Not major versions. Those change considerably over the years, and
that's why people keep tracking trunk so closely. Then again, most
people that track trunk have teams big enough to cope with it. Those
that don't, generally prefer to stick to specific versions and hope
that the change log is enough to help them migrate.

cheers,
--renato