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

[Joachim Durchholz via llvm-dev]

Am 13.10.2015 um 13:56 schrieb mats petersson:
> Going from 3.6 to 3.7 would almost certainly break binary compatibility
> between .bc files. You may be able to get away with it for some particular
> use-cases (but in that case, it's by luck, not by design).
>
> I'm not enough "part of the community" to say if there are rules about what
> can and can't change between certain levels of releases, but my general
> understanding is that "as long as the change is good, it goes in" [aside
> from changes for example between 3.7.0 and 3.7.1, where there is a
> guarantee that, modulo actual bugs or undefined behaviour, the two releases
> are compatible].
>
> I try to track "trunk" by updating every two-four weeks, and once every few
> of those updates, I need to make changes to my compiler project. Of course,
> how many and what kind of changes will depend on what features of LLVM your
> project is using. There are some parts of LLVM that are very stable, there
> are others with more changes - but all appear to potentially change from my
> experience.

Thanks, that's very useful feedback.

> The "not guarantee for compatibility between releases" is a good and a bad
> thing, where the bad part is the obvious extra work when something changes,
> and the good part is that "things can be changed". I've worked on/with
> projects that have very strict rules of compatibility, where changes to ABI
> and API are very difficult to make and everything has to be motivated,
> debated, change-controlled and finally agreed with "customers" [in quotes
> as it's often some group within the overall company, but outside your own
> group]. This approach makes for slow and often complex changes to "work
> around" the fact that you can't actually make the change you want. It's a
> right pain to work with such systems too, even if it may seem like a good
> idea at times. Most importantly, it is often harming innovation and
> improvements, because of the bureaucracy involved in making changes.

Heh, I know. One style is a PITA for the infrastructure devs, the other 
is a PITA for the infrastructure users, and then we have a spectrum 
in-between.
I have yet to see a working solution for that.

Regards,
Jo