<div dir="ltr"><br><div class="gmail_extra"><br><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><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">----- Original Message -----<br>
> From: "Hans Wennborg via cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>><br>
> To: "llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>>, "cfe-dev" <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>>, "LLDB Dev" <<a href="mailto:lldb-dev@lists.llvm.org">lldb-dev@lists.llvm.org</a>>,<br>
> "openmp-dev (<a href="mailto:openmp-dev@lists.llvm.org">openmp-dev@lists.llvm.org</a>)" <<a href="mailto:openmp-dev@lists.llvm.org">openmp-dev@lists.llvm.org</a>><br>
> Cc: "r jordans" <<a href="mailto:r.jordans@tue.nl">r.jordans@tue.nl</a>>, "Paul Robinson" <<a href="mailto:Paul_Robinson@playstation.sony.com">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>At least naively, I'd expect opaque pointer types to be backwards compatible (ie: we can load old bitcode and just strip all the pointer types and bitcasts). But perhaps it still meets the bar of a big change & may be worth shedding all the backwards compatibility weight sooner rather than later after the change, for sure.<br><br>(as to the main issue - yeah, I tend to agree with you/Mehdi, etc - go to 3.10 and so on, until we decide it's worth breaking back-compat - do we need to update any wording about our back-compat guarantee that says we won't do the inverse (4.3 -> 5.0 because we decide we have another breaking change), though? Since we'll demonstrated that primary version bumps aren't on a strict ~5 year cycle anymore - probably don't need to do anything, but just a thought)<br><br>- Dave</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
 -Hal<br>
<span class="im HOEnZb"><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">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 class="HOEnZb"><font color="#888888">--<br>
Hal Finkel<br>
Assistant Computational Scientist<br>
Leadership Computing Facility<br>
Argonne National Laboratory<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">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><br></div></div>