<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi,<div class=""><div><br class=""></div><div>@Erich, thanks for putting this together :).</div><div><br class=""><blockquote type="cite" class=""><div class="">On May 11, 2018, at 9:54 AM, Daniel Berlin via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I'd be opposed to 6/5, given where it would leave us.<div class="">It's simply hard to see a compelling reason to leave things that long.</div><div class=""><br class=""></div><div class="">In particular, given this is about what it takes to produce a binary release of clang/llvm from trunk (and not what it takes to use one), i'd like to see some evidence/argument that using 3/1.5 would actually have a material affect on the number of contributions, etc.</div><div class="">(I have doubts it would have any affect on the abliity of new developers to start contributing, etc).</div></div></div></blockquote><div><br class=""></div>+ 1.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">All of the clang/llvm based tools i have around (cquery, rtags, you name it) all download and ship binary releases of clang/llvm (and FWIW, they ship and use 1-2 year old releases).</div><div class="">It's also unclear to me it makes sense to try to make sure any user can compile the latest version - for example, researchers using it almost never keep up with trunk, even with our current policy that supports things for longer. They stick with the version that existed when they started.</div></div></div></blockquote><blockquote type="cite" class=""><br class=""></blockquote><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">So it's unclear that we are doing a thing users actually want in practice anyway :)</div></div></div></blockquote><div><br class=""></div><div>Yep, I have the same doubts. Anecdotally, I've got a few hobby projects I haven't rebased since.. 3.4? I don't have a list on hand, but I've definitely seen papers from groups that do the same thing.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">Finally, given the rate of support for newer C++ standards in LLVM/GCC seems to be accelerating and not slowing down (AFAICT), keeping a time period this long will just put you farther and farther behind over time.</div></div></div></blockquote><div><blockquote type="cite" class=""><br class=""></blockquote></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="">It may be better to simply express it in terms of releases, and say "we support the past 2/3 major gcc releases, the past 2/3 major clang releases, and the past 2 major msvc releases"</div></div></div></blockquote><div><br class=""></div><div>I'd prefer this to imposing a fixed wait period of 3 years. We could add a deprecation warning for compiler version X when (X+1) is released, and switch to (X+1) when (X+2) is out. I can see this breaking down if some LTS distro continues to ship version X, but that's in issue in the 3/1.5 scheme as well, and we can make specific exceptions as needed.</div><div><br class=""></div><div>I see the 3/1.5 scheme as basically a more conservative version of this, so I'd be OK with that too.</div><div><br class=""></div><div>vedant</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class=""><br class=""></div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, May 11, 2018 at 8:58 AM, Andrew Kelley via llvm-dev <span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="">I second this proposal, and I make a motion to lengthen 3/1.5 to 6/5.<br class=""></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br class=""><div class="gmail_quote">On Fri, May 11, 2018 at 9:37 AM, Keane, Erich via llvm-dev <span dir="ltr" class=""><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi All-<br class="">
As we all know, the C++14 discussion is flaring up again. Chandler brought up that he would like a concrete plan to switch. In my opinion, this is insufficient, as it will result in us simply having this discussion AGAIN next release. Instead, I would prefer us to have a concrete Policy on our host compilers. That way, changes like this are unsurprising to our users, and advance our codebase sufficiently. I believe the arguments for/against upgrading have been made repeatedly, so I won't repeat them here. My proposal is thus:<br class="">
<br class="">
Starting with the Clang 7.0 release, we will officially support any major release of our host compilers (MSVC, GCC, Clang, ?ICC?) released in the past 3* years from our previous branch date to give trunk-developers time to transition (so for 7.0, 3 years before January 3, 2018). This will be enforced via the CMake CheckCompilerVersion script (ala <a href="https://reviews.llvm.org/D46723" rel="noreferrer" target="_blank" class="">https://reviews.llvm.org/D4672<wbr class="">3</a>). ADDITIONALLY, a CMake warning will be issued for any major release less than 1.5* years old to give our users sufficient time to transition/upgrade their compilers. Finally, our dependent C++ version will be the best released standard officially supported by the collection of compilers (for example, we'd support -C++20 if all compilers had std=c++20 or eqiv, but NOT std=c++2a). <br class="">
<br class="">
The 3-years/1.5 years would result in our minimum GCC/Clang becoming: GCC5.1/Clang3.6. We would WARN on anything older than GCC7.1/Clang3.8<br class="">
<br class="">
/End Proposal<br class="">
<br class="">
<br class="">
*: To Be Bikeshed<br class="">
______________________________<wbr class="">_________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">
</blockquote></div><br class=""></div>
</div></div><br class="">______________________________<wbr class="">_________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank" class="">http://lists.llvm.org/cgi-bin/<wbr class="">mailman/listinfo/llvm-dev</a><br class="">
<br class=""></blockquote></div><br class=""></div>
_______________________________________________<br class="">LLVM Developers mailing list<br class=""><a href="mailto:llvm-dev@lists.llvm.org" class="">llvm-dev@lists.llvm.org</a><br class="">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev<br class=""></div></blockquote></div><br class=""></div></body></html>