llvm dev - Oct 2015 - Should I worry about test failures in a release?

On 12 October 2015 at 16:29, Joachim Durchholz via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I've been planning to switch to a new release whenever it's out.
> What are the advantages of following trunk?
Some people prefer following releases and having a higher cost when
migrating, other people prefer to spread the cost over many months,
but you'll have to resolve conflicts most of the time you re-base your
project regardless of what you choose.

If you stick to a release...

Pros:
 * ABI stability
 * Known functionality (ie. no experimental stuff)
 * Re-base can be done separately, and merged once stable
Cons:
 * Known problems are less likely to be fixed upstream (1)
 * Larger re-base periods, may invalidate a lot of your bridge code

If you stick to trunk...

Pros:
 * Faster re-base periods
 * Bugs are more likely to be fixed quickly
 * New features, target support will come earlier
 * You can influence/propose/submit changes upstream
Cons:
 * Unpredictable re-base. Sometimes, a re-base can destroy a lot of stuff.
 * You'll have to track buildbots to make sure all targets are green
on the revision you want to pull
 * You won't have the additional validation people do on releases
(larger code-bases, benchmarks, etc).
 * Re-bases are better done as a "stop the press" moment in the
project history, may delay other tasks

Ultimately, it depends on how you and your team work, and how you
expect the software you're building to evolve. The vast majority of
people stick to trunk.

cheers,
--renato

(1) The community is very focused on trunk, so problems fixed on trunk
may not be easily back-ported. You may want to do the back-port
yourself, but that still doesn't mean people will accept it on the
release branch, for example, due to potential instability concerns.
Releases are more "stable points in time", than proper products.

Am 12.10.2015 um 18:26 schrieb Renato Golin:
> Some people prefer following releases and having a higher cost when
> migrating, other people prefer to spread the cost over many months,
> but you'll have to resolve conflicts most of the time you re-base your
> project regardless of what you choose.
Oh... why do I need to rebase?
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.

A different but related questons: Are minor releases of LLVM 
backwards-compatible? 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?

Regards,
Jo

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