On Mon, Feb 12, 2018 at 11:58 AM, Michael Park <mp...@apache.org> wrote:
> On Mon, Feb 12, 2018 at 10:32 AM, Zhitao Li <zhitaoli...@gmail.com> wrote: > > > Will there be a deprecation cycle for the proposed change? > > > There is no deprecation cycle for the proposed change. > I take that the moment we decide this, c++ features which requires gcc >=5 will be used? > > > > Our org still uses Debian Jessie and we do not see ourselves off that > > before EOY. > > > This is great! Thanks for sharing. Could you please clarify what "uses" > mean here? > I'm guessing it means that the dev servers that you develop on run Jessie, > but > wanted to clarify. > A (big) part of our production fleet, our dev servers and our package release process are all using Debian Jessie. I guess we need to test out whether running Mesos built with newer version of gcc (also glibc) on older version of distro is safe. If so, my team will only have dev environment to worry about (which is at a much smaller scale to deal with). > Thanks! > > MPark > > > > On Mon, Feb 12, 2018 at 8:38 AM, James Peach <jpe...@apache.org> wrote: > > > > > > > > > > > > On Feb 11, 2018, at 10:33 PM, Michael Park <mcyp...@gmail.com> > wrote: > > > > > > > > On Sun, Feb 11, 2018 at 6:00 PM James Peach <jpe...@apache.org> > wrote: > > > > > > > >> > > > >> > > > >>> On Feb 9, 2018, at 9:28 PM, Michael Park <mp...@apache.org> wrote: > > > >>> > > > >>> I'm going to put this up for a vote. My plan is to bump us to C++14 > > on > > > >> Feb > > > >>> 21. > > > >>> > > > >>> The following are the proposed changes: > > > >>> - Minimum GCC *4.8.1* => *5*. > > > >>> - Minimum Clang *3.5* => *3.6*. > > > >>> - Minimum Apple Clang *8* => *9*. > > > >>> > > > >>> We'll have a standard voting, at least 3 binding votes, and no -1s. > > > >> > > > >> +0 > > > >> > > > >> What’s the user benefit of this change? > > > >> > > > > > > > > Some of the features I've described in MESOS-7949 > > > > <https://issues.apache.org/jira/browse/MESOS-7949> are: > > > > > > > > - Generic lambdas > > > > - New lambda captures (Proper move captures!) > > > > - SFINAE result_of (We can remove stout/result_of.hpp) > > > > - Variable templates > > > > - Relaxed constexpr functions > > > > - Simple utilities such as std::make_unique > > > > - Metaprogramming facilities such as decay_t, index_sequence > > > > > > Are these all internal though? Maybe move captures could yield some > > > performance improvements? > > > > > > > > > > > > -- > > Cheers, > > > > Zhitao Li > > > -- Cheers, Zhitao Li
