<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 19, 2016, at 12:25 AM, Hal Finkel <<a href="mailto:hfinkel@anl.gov" class="">hfinkel@anl.gov</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><blockquote style="font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; border-left-width: 2px; border-left-style: solid; border-left-color: rgb(16, 16, 255); margin-left: 5px; padding-left: 5px; text-decoration: none; font-family: Helvetica, Arial, sans-serif; font-size: 12pt;" class=""><div class="">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 class="">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 class="">c) I think that it makes sense to keep adding 0.1 to each major release going forward well into the future.</div><div class=""><br class=""></div><div id="DWT1817" class="">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><span style="font-family: arial, helvetica, sans-serif; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">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.</span><br style="font-family: arial, helvetica, sans-serif; font-size: 13px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""></div></blockquote></div><br class=""><div class="">API breakage isn’t a concern, every release of LLVM breaks APIs. I don’t see a reason to “delay” LLVM 4.0.</div><div class=""><br class=""></div><div class="">-Chris</div></body></html>