What happens for the users using spark 1.5 that run with Java 7 only ?
On Oct 18, 2017, 12:06, at 12:06, "Ismaël Mejía" <ieme...@gmail.com> wrote: >+1 > >I forgot to vote yesterday, I don't really think this is a change >worth requiring a major version of Beam. Just clear information in the >site/release notes should make it. Also I am afraid that if we wait >until we have enough changes to switch Beam to a new major version the >switch to Java 8 will happen too late, probably after Java 8's end of >life. And I am not exaggerating, Java 8 is planned to EOL next march >2018! (of course Oracle usually changes this), in any case go go Java >8 ASAP ! > > >On Wed, Oct 18, 2017 at 8:08 AM, Prabeesh K. <prabsma...@gmail.com> >wrote: >> +1 >> >> On 18 October 2017 at 05:16, Griselda Cuevas <g...@google.com> wrote: >>> >>> +1 >>> >>> On 17 October 2017 at 16:36, Robert Bradshaw <rober...@google.com> >wrote: >>>> >>>> +1 to removing Java 7 support, pending no major user outcry to the >>>> contrary. >>>> >>>> In terms of versioning, I fall into the camp that this isn't >>>> sufficiently incompatible to warrant a major version increase. >>>> Semantic versioning is all about messaging, and upgrading the major >>>> version so soon after GA for such a minor change would IMHO cause >more >>>> confusion that clarity. Hitting 3.0 should signal a major >improvement >>>> to Beam itself. >>>> >>>> On Tue, Oct 17, 2017 at 3:52 PM, Eugene Kirpichov ><kirpic...@google.com> >>>> wrote: >>>> > +1 to removing Java 7 support. >>>> > >>>> > In terms of release 3.0, we can handle this two ways: >>>> > - Wait until enough other potentially incompatible changes >accumulate, >>>> > do >>>> > all of them, and call it a "3.0" release, so that 3.0 will truly >differ >>>> > in a >>>> > lot of incompatible and hopefully nice ways from 2.x. This might >well >>>> > take a >>>> > year or so. >>>> > - Make a release in which Java 7 support is removed, and call it >a >>>> > "3.0" >>>> > release just to signal the incompatibility, and other potentially >>>> > incompatible changes will wait until "4.0" etc. >>>> > >>>> > I suppose the decision depends on whether we have a lot of other >>>> > incompatible changes we would like to do, and whether we have any >other >>>> > truly great features enabled by those changes, or at least truly >great >>>> > features justifying increasing the major version number. If we go >with >>>> > #1, >>>> > I'd say, among the current work happening in Beam, portability >comes to >>>> > mind >>>> > as a sufficiently huge milestone, so maybe drop Java 7 in the >same >>>> > release >>>> > that offers a sufficient chunk of the portability work? >>>> > >>>> > (There's also a third path: declare that dropping Java7 support >is not >>>> > sufficiently "incompatible" to warrant a major version increase, >>>> > because >>>> > people don't have to rewrite their code but only switch their >compiler >>>> > version, and people who already use a Java8 compiler won't even >notice. >>>> > This >>>> > path could perhaps be considered if we had evidence that >switching to a >>>> > Beam >>>> > release without Java7 support would require 0 work for an >overwhelming >>>> > majority of users) >>>> > >>>> > >>>> > >>>> > On Tue, Oct 17, 2017 at 3:34 PM Randal Moore ><rdmoor...@gmail.com> >>>> > wrote: >>>> >> >>>> >> +1 >>>> >> >>>> >> On Tue, Oct 17, 2017 at 5:21 PM Raghu Angadi ><rang...@google.com> >>>> >> wrote: >>>> >>> >>>> >>> +1. >>>> >>> >>>> >>> On Tue, Oct 17, 2017 at 2:11 PM, David McNeill ><dav...@mcpond.co.nz> >>>> >>> wrote: >>>> >>>> >>>> >>>> The final version of Beam that supports Java 7 should be >clearly >>>> >>>> stated >>>> >>>> in the docs, so those stuck on old production infrastructure >for >>>> >>>> other java >>>> >>>> app dependencies know where to stop upgrading. >>>> >>>> >>>> >>>> David McNeill >>>> >>>> 021 721 015 >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 18 October 2017 at 05:16, Ismaël Mejía <ieme...@gmail.com> >wrote: >>>> >>>>> >>>> >>>>> We have discussed recently in the developer mailing list >about the >>>> >>>>> idea of removing support for Java 7 on Beam. There are >multiple >>>> >>>>> reasons for this: >>>> >>>>> >>>> >>>>> - Java 7 has not received public updates for almost two years >and >>>> >>>>> most >>>> >>>>> companies are moving / have already moved to Java 8. >>>> >>>>> - A good amount of the systems Beam users rely on have >decided to >>>> >>>>> drop >>>> >>>>> Java 7 support, e.g. Spark, Flink, Elasticsearch, even Hadoop >plans >>>> >>>>> to >>>> >>>>> do it on version 3. >>>> >>>>> - Most Big data distributions and Cloud managed Spark/Hadoop >>>> >>>>> services >>>> >>>>> have already moved to Java 8. >>>> >>>>> - Recent versions of core libraries Beam uses are moving to >be Java >>>> >>>>> 8 >>>> >>>>> only (or mostly), e.g. Guava, Google Auto, etc. >>>> >>>>> - Java 8 has some nice features that can make Beam code nicer >e.g. >>>> >>>>> lambdas, streams. >>>> >>>>> >>>> >>>>> Considering that Beam is a ‘recent’ project we expect users >to be >>>> >>>>> already using Java 8. However we wanted first to ask the >opinion of >>>> >>>>> the Beam users on this subject. It could be the case that >some of >>>> >>>>> the >>>> >>>>> users are still dealing with some old cluster running on Java >7 or >>>> >>>>> have another argument to keep the Java 7 compatibility. >>>> >>>>> >>>> >>>>> So, please vote: >>>> >>>>> +1 Yes, go ahead and move Beam support to Java 8. >>>> >>>>> 0 Do whatever you want. I don’t have a preference. >>>> >>>>> -1 Please keep Java 7 compatibility (if possible add your >argument >>>> >>>>> to >>>> >>>>> keep supporting for Java 7). >>>> >>>> >>>> >>>> >>>> >>> >>>> > >>> >>> >>
