+1 On 18 October 2017 at 05:16, Griselda Cuevas <[email protected]> wrote:
> +1 > > On 17 October 2017 at 16:36, Robert Bradshaw <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >> wrote: >> >> >> >> +1 >> >> >> >> On Tue, Oct 17, 2017 at 5:21 PM Raghu Angadi <[email protected]> >> wrote: >> >>> >> >>> +1. >> >>> >> >>> On Tue, Oct 17, 2017 at 2:11 PM, David McNeill <[email protected]> >> >>> 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 <[email protected]> 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). >> >>>> >> >>>> >> >>> >> > >> > >
