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

On 11 October 2015 at 21:46, Joachim Durchholz via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Since I plan to use LLVM as a backend, not hack on it, I'm not going to
get
> much joy out of TRUNK, so I reverted to 3.7.
> Which led me to the realization that GettingStarted does not mention
> libcxxabi.
That depends on what you use. If you use libc++, then you need to
worry about those tests.

Releases are done with the components that are known to work on the
platform. For example, 3.7 was the first that I bundled the sanitizers
for AArch64, since it's the first that we can claim support. I plan to
release libc++ too, once it's stable, even if the example
documentation doesn't explicitly mention it, the test-release.sh
script can build and test it.

Regarding trunk vs release, it depends on what you need. If your
project will use LLVM for a long time (ie. if this is a serious long
term project), then you should follow trunk as closely as possible. If
this is just a trial project, then following a release is better,
because you can focus on your project only and you'll always be able
to build it targeting a specific release in the future, not having to
track which commits off trunk were good.

cheers,
--renato

Am 12.10.2015 um 13:52 schrieb Renato Golin:
> On 11 October 2015 at 21:46, Joachim Durchholz via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> Since I plan to use LLVM as a backend, not hack on it, I'm not
going to get
>> much joy out of TRUNK, so I reverted to 3.7.
>> Which led me to the realization that GettingStarted does not mention
>> libcxxabi.
>
> That depends on what you use. If you use libc++, then you need to
> worry about those tests.
Ah. I guess I'll want that once I have a working toolchain.
> Regarding trunk vs release, it depends on what you need. If your
> project will use LLVM for a long time (ie. if this is a serious long
> term project),
It's going to be a compiler project. The usual setup: C++ for 
scanner/parser/AST/diagnostics, LLVM for the backend. Self-hosting 
comiler may happen later, and will continue to use LLVM.
So my plans for using LLVM are long-term, and at least mid-term for Clang.

 > then you should follow trunk as closely as possible.
If
> this is just a trial project, then following a release is better,
> because you can focus on your project only and you'll always be able
> to build it targeting a specific release in the future, not having to
> track which commits off trunk were good.
I've been planning to switch to a new release whenever it's out.
What are the advantages of following trunk?

Regards,
Jo

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.