<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">And outlook still strips llvm-dev sometimes when replying-to-all (didn’t we already get rid of that problem?)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Argh.<o:p></o:p></span></p>
<p class="MsoNormal"><a name="_MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></a></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Kuperstein, Michael M
<br>
<b>Sent:</b> Tuesday, October 13, 2015 15:44<br>
<b>To:</b> 'mats petersson'; Joachim Durchholz<br>
<b>Subject:</b> RE: [llvm-dev] Should I worry about test failures in a release?<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">As far as I know, the consensus was that all 3.x versions should retain backward compatibility for bitcode.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Michael<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> llvm-dev [<a href="mailto:llvm-dev-bounces@lists.llvm.org">mailto:llvm-dev-bounces@lists.llvm.org</a>]
<b>On Behalf Of </b>mats petersson via llvm-dev<br>
<b>Sent:</b> Tuesday, October 13, 2015 14:57<br>
<b>To:</b> Joachim Durchholz<br>
<b>Cc:</b> LLVM Dev<br>
<b>Subject:</b> Re: [llvm-dev] Should I worry about test failures in a release?<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt;line-height:115%">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).<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt;line-height:115%">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].<o:p></o:p></p>
</div>
<p class="MsoNormal" style="line-height:115%">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.
<br>
<br>
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.
<br>
<br>
--<o:p></o:p></p>
</div>
<p class="MsoNormal" style="line-height:115%">Mats<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="line-height:115%"><o:p> </o:p></p>
<div>
<p class="MsoNormal" style="line-height:115%">On 13 October 2015 at 12:40, Joachim Durchholz via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal" style="line-height:115%">Thanks, that answered all questions.<br>
<br>
One last detail: What's a major version? 3.8 or 4.0?<br>
<br>
Regards,<br>
Jo<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal" style="line-height:115%"><br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></p>
</div>
</div>
</div>
<p class="MsoNormal" style="line-height:115%"><o:p> </o:p></p>
</div>
</div>
<p>---------------------------------------------------------------------<br>
Intel Israel (74) Limited</p>
<p>This e-mail and any attachments may contain confidential material for<br>
the sole use of the intended recipient(s). Any review or distribution<br>
by others is strictly prohibited. If you are not the intended<br>
recipient, please contact the sender and delete all copies.</p></body>
</html>