+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. <[email protected]> wrote: > +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). >>> >>>> >>> >>>> >>> >>> >>> > >> >> >
