<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 21, 2016 at 7:56 AM Chris Lattner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Jun 19, 2016, at 10:21 AM, Adve, Vikram Sadanand via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br>
>>> Let me clarify. What I’m trying to say is that:<br>
>><br>
>>> a) LLVM has a time-based release cycle, not a schedule-based one. As<br>
>>> such, a simple and predictable version number makes sense.<br>
>>> b) The LLVM project as a whole is a lot bigger than LLVM IR, even<br>
>>> given its centrality to the project in some ways.<br>
>>> c) I think that it makes sense to keep adding 0.1 to each major<br>
>>> release going forward well into the future.<br>
><br>
><br>
> 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.?<br>
<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.<br></blockquote><div><br></div><div>I'm sympathetic to the idea that we should move to a sliding window for IR compatibility if that's useful.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>-Chandler</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> If so, I agree with that for a couple of reasons.  First, as several people said, version numbers should not be driven primarily by IR changes: the LLVM project is a lot more than the IR, even though the IR is a fundamental component.  Our releases are time-based and the predictability of that has worked pretty well.<br>
><br>
> A second reason is that major version numbers also have a useful communication value: signifying a major step forward in the system along some dimension.  It just so happens that these major changes have been IR changes in the past -- and perhaps opaque pointer types will turn out to be the next major change -- but regardless of what the change is, I think there is some value in reserving major version increments (like 3.x.y to 4.0) when major changes happen.<br>
<br>
These seem like contradictory points: on the one hand you’re observing that we have an inherently schedule driven process, but are also saying that major version numbers are important to signify “major” changes.  Given the scope of LLVM, I suspect we’ll never have a “major” change that lines up across all of the sub-projects, so this doesn’t seem like something we should bank on.<br>
<br>
I don’t think that there is really a problem to solve here, but if we were sufficiently motivated to “solve” this problem, then the answer is obvious: instead of 4.0, we should just go to 40, and add one for every release after that.<br>
<br>
-Chris<br>
<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" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>