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

Tue Oct 13 06:13:28 PDT 2015

Sadly not. I've sent myself a large number of emails via hand-typed SMTP to figure out the cause of the problem and IIRC it's a bug in the order changes are made to the recipient list. It seems Outlook builds a recipient list, removes duplicates, and then swaps the From for the Reply-To. One copy of llvm-dev (from the CC) gets lost in the process. Putting llvm-dev in 'To' rather than 'CC' seems to work around it.

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Kuperstein, Michael M via llvm-dev
Sent: 13 October 2015 13:46
To: mats petersson; Joachim Durchholz
Cc: llvm-dev at lists.llvm.org
Subject: Re: [llvm-dev] Should I worry about test failures in a release?

And outlook still strips llvm-dev sometimes when replying-to-all (didn’t we already get rid of that problem?)
Argh.

From: Kuperstein, Michael M
Sent: Tuesday, October 13, 2015 15:44
To: 'mats petersson'; Joachim Durchholz
Subject: RE: [llvm-dev] Should I worry about test failures in a release?

As far as I know, the consensus was that all 3.x versions should retain backward compatibility for bitcode.

So, 3.7 should be able to consume bitcode (but not text IR) produced by any earlier 3.x. When 4.0 rolls around, all bets are off.
Note that “consume” here is a not as strong a guarantee as it may sound, since metadata may be stripped off. Debug metadata almost certainly will be.

Michael

From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of mats petersson via llvm-dev
Sent: Tuesday, October 13, 2015 14:57
To: Joachim Durchholz
Cc: LLVM Dev
Subject: Re: [llvm-dev] Should I worry about test failures in a release?

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.

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.

--
Mats

On 13 October 2015 at 12:40, Joachim Durchholz via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
Thanks, that answered all questions.

One last detail: What's a major version? 3.8 or 4.0?

Regards,
Jo

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20151013/bd1376eb/attachment.html>