On Tue, Oct 4, 2016 at 8:29 AM, Zachary Turner <zturner at google.com> wrote:> > I ask because many of these LTS distros are notoriously slow at updating > their packages. While some people may think C++14 doesn't provide enough > bang for the buck to justify bumping to GCC 4.9, C++17 definitely does. But > at that point we're going to be talking about GCC 6.1 or 6.2, which is > going to be significantly harder unless we want to wait 5-7 years, and I > suspect people won't. >If by "notoriously slow" you mean they don't bump their toolchain versions at all, then yeah. We just wait until the LTS release is at end-of-life before dropping it. That means we need to have at least two years of support. Forcing people to upgrade their distro every two years is still pretty annoying, and I'd rather not do it without a compelling reason. Seriously, I think we can survive another year without generic lambdas and generalized constexpr. P.S. 11 days until we drop MSVC 2013 :) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161004/a4949020/attachment.html>
> On Oct 4, 2016, at 8:40 AM, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Tue, Oct 4, 2016 at 8:29 AM, Zachary Turner <zturner at google.com <mailto:zturner at google.com>> wrote: > I ask because many of these LTS distros are notoriously slow at updating their packages. While some people may think C++14 doesn't provide enough bang for the buck to justify bumping to GCC 4.9, C++17 definitely does. But at that point we're going to be talking about GCC 6.1 or 6.2, which is going to be significantly harder unless we want to wait 5-7 years, and I suspect people won't. > > If by "notoriously slow" you mean they don't bump their toolchain versions at all, then yeah. We just wait until the LTS release is at end-of-life before dropping it.That’s the first time I read about this policy: we support every linux LTS distribution till their end-of-life? Only Ubuntu? Do you have a pointer where it is documented / discussed? (Note that Ubuntu LTS is 5 years AFAIK.)> Forcing people to upgrade their distro every two years is still pretty annoying, and I'd rather not do it without a compelling reason.I agree with this.> Seriously, I think we can survive another year without generic lambdas and generalized constexpr.As much as I like these new toys, I tend to agree with this as well FWIW. — Mehdi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161004/492e13a8/attachment.html>
On Tue, Oct 4, 2016 at 11:58 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:> > On Oct 4, 2016, at 8:40 AM, Reid Kleckner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > > On Tue, Oct 4, 2016 at 8:29 AM, Zachary Turner <zturner at google.com> wrote: >> >> I ask because many of these LTS distros are notoriously slow at updating >> their packages. While some people may think C++14 doesn't provide enough >> bang for the buck to justify bumping to GCC 4.9, C++17 definitely does. But >> at that point we're going to be talking about GCC 6.1 or 6.2, which is >> going to be significantly harder unless we want to wait 5-7 years, and I >> suspect people won't. >> > > If by "notoriously slow" you mean they don't bump their toolchain versions > at all, then yeah. We just wait until the LTS release is at end-of-life > before dropping it. > > > That’s the first time I read about this policy: we support every linux LTS > distribution till their end-of-life? Only Ubuntu? Do you have a pointer > where it is documented / discussed? > (Note that Ubuntu LTS is 5 years AFAIK.) >Sorry, I didn't mean to refer to the LTS support lifetime. I just meant we support the last LTS until we can reasonably expect users to have upgraded to the new one. If there's an LTS release every two years, then we want to keep supporting them for at least three years to give people a year to upgrade. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20161004/6c184695/attachment.html>