<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:0in;
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;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
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">Hm. Intriguing. Then each release would have to specify (somehow) what its specific IR compatibility range is.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Release 47 supports bitcode back to release 3.9 (say), release 54 compatible back to release 44, etc where the "back to" number is not clearly predictable.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">(This would be easier to implement if bitcode reliably had a produced-by-version number in it.)<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">--paulr<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 style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<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 [mailto:llvm-dev-bounces@lists.llvm.org]
<b>On Behalf Of </b>Chris Lattner via llvm-dev<br>
<b>Sent:</b> Tuesday, June 21, 2016 9:29 PM<br>
<b>To:</b> Chandler Carruth<br>
<b>Cc:</b> llvm-dev@lists.llvm.org; llvm-dev-request@lists.llvm.org; Vikram Adve<br>
<b>Subject:</b> Re: [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">On Jun 20, 2016, at 11:38 PM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>> wrote:<o:p></o:p></p>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">> Now you’re making the versions sound like floating point numbers :-). Just to be clear, you are proposing we use 3.10/3.11/etc. rather than 4.0/4.1/etc.?<o:p></o:p></p>
<div>
<div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<p class="MsoNormal"><br>
No, I’m suggesting that we continue the progression we’ve had from the start and proceed from 3.8 to 3.9 to 4.0 to 4.1.<o:p></o:p></p>
</blockquote>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I'm sympathetic to the idea that we should move to a sliding window for IR compatibility if that's useful.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">However, I think it is a really big mistake to *have* a major version and just increment it arbitrarily without any associated "major" change. Lacking us explaining what we consider to be a major release, people will make assumptions that
will inevitably lead to missed expectations.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If we want to have a major/minor split, I think we need to have *some* guidance for what will constitute a major jump. I don't think it needs to necessarily be formulaic (like bitcode compatibility), it could be when a feature happens to
be ready and happens to be decided by the community to be "big enough" we flip the major version and announce that feature happened to be ready. But we shouldn't just go from 3.9 to 4.0 because of some decimal correspondence. Too many people will assume it
had significance and become disappointed.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If we *don't* want a major/minor split, then I believe Richard's suggestion is the correct one: just have integers to mark the temporal releases, and dot releases for updates to that release branch.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I personally don't have strong feelings about whether we should or shouldn't have a major/minor split. I see arguments on both sides. But I really do not want us to have a *meaningless* split.<o:p></o:p></p>
</div>
</div>
</div>
</div>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I can see your point about our current naming scheme being confusable with semantic versioning, but I don't think the risk is high and I don’t think the problem is solving. That is just MHO of course, and I totally respect and understand
that reasonable people would disagree with that.<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">What I care most about is aligning our versioning scheme with the practical realities of how we manage the software, and giving our users some idea of what we ship. I do not think it is reasonable at all to go to “3.10” after “3.9”, because
we will never get to “4.0”. The GCC community has been through this (as one example) where they could never decide on when to bump to 5.0. They resolved the issue by going to the completely insane (again, IMVHO :-) version scheme they have now.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The desire to align the version with how we release the product is what leads me to think that the only rationale solution is to increment the version number predictably with every release: we have a time based release. I don’t care if
that is by adding 0.1 or by adding 1.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">That is why I suggested that - if you believe that consistently adding 0.1 is confusing - then the logical answer is to jump to "version 40” with the post-3.9 major release and then add 1 on every other release after that. Here are the
advantages I see:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> - This communicates clearly and obviously to users that we changed policy with the version number scheme<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - Offers continuity with the prior approach (3.9 -> 40 is something that people will be able to remember)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - Aligns the new version number scheme with how the project is managed<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - Aligns the version numbers with the expectations of semantic versioning (since every release of LLVM is API breaking). Compatible bugfix/patch releases can then be “dot” releases of the major number, again aligning with semantic versioning.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">The only downside I see to this is that people will think that it is crazy that LLVM has had so many incompatible releases, but hey, why hide the truth? :-)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">-Chris<o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>