[llvm-dev] Should I worry about test failures in a release?
Kuperstein, Michael M via llvm-dev
llvm-dev at lists.llvm.org
Tue Oct 13 05:45:35 PDT 2015
And outlook still strips llvm-dev sometimes when replying-to-all (didn’t we already get rid of that problem?)
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.
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.
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?
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
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...
More information about the llvm-dev