+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). >>>> >>>> >>> >
