<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: arial,helvetica,sans-serif; font-size: 10pt; color: #000000'><br><hr id="zwchr"><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><b>From: </b>"Chris Lattner via Openmp-dev" <openmp-dev@lists.llvm.org><br><b>To: </b>"Chris Lattner" <clattner@apple.com><br><b>Cc: </b>"llvm-dev" <llvm-dev@lists.llvm.org>, "openmp-dev (openmp-dev@lists.llvm.org)" <openmp-dev@lists.llvm.org>, "LLDB Dev" <lldb-dev@lists.llvm.org>, "Richard Smith" <richard@metafoo.co.uk>, "cfe-dev" <cfe-dev@lists.llvm.org>, "Paul Robinson" <Paul_Robinson@playstation.sony.com><br><b>Sent: </b>Saturday, June 18, 2016 11:20:19 PM<br><b>Subject: </b>Re: [Openmp-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)<br><br>
<br class=""><div><blockquote class=""><div class="">On Jun 18, 2016, at 9:16 PM, Chris Lattner via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word;" class="">On Jun 14, 2016, at 1:32 AM, Richard Smith via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" class="" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<div class=""><blockquote class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">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 class=""></blockquote><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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></div></blockquote><br class=""></div><div class="">I completely agree with Richard here. “Breaking of IR compatibility” was an interesting metric for older and less mature versions of LLVM. We can solve the same sort of challenge (the desire to eject old autoupgrade code) by having a sliding window of versions supported (e.g. version 4.5 supports back to version 3.6).</div></div></div></blockquote><br class=""></div><div>Let me clarify. What I’m trying to say is that:</div><div><br class=""></div><div>a) LLVM has a time-based release cycle, not a schedule-based one. As such, a simple and predictable version number makes sense.</div><div>b) The LLVM project as a whole is a lot bigger than LLVM IR, even given its centrality to the project in some ways.</div><div>c) I think that it makes sense to keep adding 0.1 to each major release going forward well into the future.</div><div><br class=""></div><div id="DWT1817">On the topic of the pointer changes proposed, I really don’t think the community is served by waiting for that. The supposition seems to be that we’d land it *without* upgrade support, but then bump the major version number to indicate this. If that’s the proposal, I think that doing such a thing would be disastrous for the LLVM community as a whole</div></blockquote>To be clear, that's not at all what I was saying. The plan has always been to have upgrade support. My thought was that once the pointer changes land, it will mean major changes in how many frontends and IR transformations use the API. A lot of out-of-tree frontends and passes support multiple versions of LLVM, and use ifdefs to work around relevant API changes. For the most part, this works reasonably, and the changes necessary between versions are not often large (perhaps especially because we have time-based releases). I suspect, however, that the amount of code changes necessary to adapt for the pointer changes will be much larger, and so calling that a new major version seems fitting.<br><br> -Hal<br><blockquote style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; color: rgb(0, 0, 0); font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;"><div>: we need to have at least some sliding window of support for older formats.</div><div><br class=""></div><div>-Chris</div><br class=""><br>_______________________________________________<br>Openmp-dev mailing list<br>Openmp-dev@lists.llvm.org<br>http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev<br></blockquote><br><br><br>-- <br><div><span name="x"></span>Hal Finkel<br>Assistant Computational Scientist<br>Leadership Computing Facility<br>Argonne National Laboratory<span name="x"></span><br></div></div></body></html>