On Mon, 2016-04-18 at 15:01 -0700, Geoffrey Garen wrote: > GCC 4.8 is three years old.
Yeah, unfortunately no Linux distros are ever willing to do major compiler upgrades, even Fedora is only willing to take minor compiler upgrades, so our willingness to support old compilers is proportional to the size of our user base eligible for updates. :/ I understand resistance to restoring support for a compiler we previously decided to drop, so let me tone down my request: I just ask that when we decide to drop support for a compiler, we consider which major distros actually shipping our updates still use that compiler, so we can get a feel for how many users will stop getting WebKit updates as a consequence. We've just recently gotten to the point where a few distros are beginning to take our updates, and I'm really hoping to facilitate this by maintaining support for the compilers these distros are using as long as possible. It's really annoying to be stuck catering to older compilers, but I don't see any good solution to this without throwing users under the bus. :( > I don’t think we should put a three year hold on all current and > future C++ language features. > > Vendors that want to ship security updates to old, stable OS’s should > maintain a branch that cherry-picks fixes from trunk and applies > build fixes as necessary, rather than holding back development in > trunk. I'm not aware of any distributor that has ever attempted to seriously backport security fixes; not even enterprise distros like RHEL do this. Reality is that distros only ship what we release upstream. > > It's unfortunate as of course we want to be able to use new > language > > features, but we need to balance this with the desire to ensure our > > updates reach users. > > I don’t think that shipping trunk as a security update on very old > platforms is a viable strategy. Nobody ships trunk, they ship our stable releases, which branch off of trunk every six months. We don't have the resources to maintain compiler support outside of trunk. Michael _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev