<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, Jun 14, 2016 at 1:32 AM Richard Smith via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 13, 2016 at 5:03 PM, Hal Finkel via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>----- Original Message -----<br>
> From: "Hans Wennborg via cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>><br>
> To: "llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>, "cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>>, "LLDB Dev" <<a href="mailto:lldb-dev@lists.llvm.org" target="_blank">lldb-dev@lists.llvm.org</a>>,<br>
> "openmp-dev (<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a>)" <<a href="mailto:openmp-dev@lists.llvm.org" target="_blank">openmp-dev@lists.llvm.org</a>><br>
> Cc: "r jordans" <<a href="mailto:r.jordans@tue.nl" target="_blank">r.jordans@tue.nl</a>>, "Paul Robinson" <<a href="mailto:Paul_Robinson@playstation.sony.com" target="_blank">Paul_Robinson@playstation.sony.com</a>><br>
> Sent: Monday, June 13, 2016 6:54:19 PM<br>
> Subject: [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)<br>
><br>
> Breaking this out into a separate thread since it's kind of a<br>
> separate<br>
> issue, and to make sure people see it.<br>
><br>
> If you have opinions on this, please chime in. I'd like to collect as<br>
> many arguments here as possible to make a good decision. The main<br>
> contestants are 4.0 and 3.10, and I've seen folks being equally<br>
> surprised by both.<br>
><br>
> Brain-dump so far:<br>
><br>
> - After LLVM 1.9 came 2.0, and after 2.9 came 3.0; naturally, 4.0<br>
> comes after 3.9.<br>
><br>
> - There are special bitcode stability rules [1] concerning major<br>
> version bumps. 2.0 and 3.0 had major IR changes, but since there<br>
> aren't any this time, we should go to 3.10.<br>
><br>
> - The bitcode stability rules allow for breakage with major versions,<br>
> but it doesn't require it, so 4.0 is fine.<br>
><br>
> - But maybe we want to save 4.0 for when we do have a significant IR<br>
> change?<br>
<br>
</span>I think that this is the right approach, and we happen to have a natural forcing function here: opaque pointer types. I think we should increment the major version number when opaque pointer types are here, as it will be a major breaking change, and then we'll have a version 4.0. Until then, unless something else breaking comes up, 3.10 sounds fine to me.<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>We're talking about version numbers for the entire LLVM project here, which encompasses a lot more than LLVM IR, and for many parts of which LLVM IR is utterly irrelevant. I'm not convinced that tying version numbers to backwards-incompatible changes to IR is reasonable any more, and it doesn't seem hard to explicitly document the oldest version with which we are compatible (in fact, we need to do that regardless, whether we say it's "the same major version" or "everything since 3.0" or whatever else).</div><div><br></div><div>Given that our releases are time-based rather than feature-based, I don't see a distinct major / minor version being anything other than arbitrary, so I'd suggest we take 4.0 as our next release, 4.1 as the first patch release on that, 5.0 as the next release after that, and so on.</div></div></div></div></blockquote><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">This seems oddly familiar.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">So, one point is that LLVM's IR compatibility impacts more projects than many other things do:</span></div><div><span style="line-height:1.5">- Clang generates bitcode with '-flto' and cares about compatibility with it.</span></div><div><span style="line-height:1.5">- LLD imports bitcode for LTO and cares about compatibility with it.</span></div><div><span style="line-height:1.5"><br></span></div><div><span style="line-height:1.5">Certainly, LLDB and libc++ are both ... substantially less impacted.</span></div><div><br></div><div>All that said, I'm not opposed to a dramatically simpler version numbering scheme which just counts cycles provided we also establish some strategy for marking the bitcode compatibility requirements.</div><div><br></div><div>But I also don't see it as an important change to make right now.</div><div>-Chandler</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 -Hal<br>
<span><br>
><br>
> - We've never had an x.10 version before; maybe that would be<br>
> confusing? Perhaps it's simply time to move on (like Linux 2.6.39 -><br>
> 3.0 and 3.19 -> 4.0).<br>
><br>
> - Since we do time-based rather than feature-based releases, the<br>
> major<br>
> version number shouldn't mean anything special anyway (e.g. big IR<br>
> changes or not), so 4.0?<br>
><br>
> - Everyone knows that after 9 comes 10, so 3.10 it is. The version is<br>
> a tuple after all.<br>
><br>
> - Let's go for 4.0 now, and 5.0 after that. Then the "dot"-releases<br>
> in<br>
> between would correspond to minor version bumps, which would make<br>
> sense (and catch up with GCC!).<br>
><br>
> - It's just a number, no big deal; flip a coin or something.<br>
><br>
> What do you think?<br>
><br>
>  - Hans<br>
><br>
><br>
>  [1].<br>
>  <a href="http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility" rel="noreferrer" target="_blank">http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility</a><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
><br>
<br>
</span><span><font color="#888888">--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</font></span><div><div>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div></div></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>