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