Here are some mostly unorganized thoughts Good ideas: Moving to java 8 for security patches Moving to new jetty for bug fixes (admittedly, I did not peruse them all)
Bad ideas: Changing backwards compatibility without bumping that first number. Not having a definition of what we mean by backwards compatibility Already having a support branch to continue to support java 7 Not having a discussion about how to best use new features in java 8 in the framework (especially if the support branch is the way forward) On Wed, Jun 17, 2015 at 6:31 AM, Sean Busbey <[email protected]> wrote: > It's important that we get some testing and compilation with java 8 > verified before we start advising downstream about the coming change. > > Maybe a good goal for 0.3.0 is getting whatever testing we do on java 7 > duplicated for java 8? > > -- > Sean > On Jun 17, 2015 7:09 AM, "Bryan Bende" <[email protected]> wrote: > > > I like the idea of targeting 1.0.0 and starting to advertise now that > Java > > 8 is coming, that way people have time to upgrade ahead of the release if > > they want to. Not sure what other projects do, but is there a good way to > > keep reminding the community that this is coming? maybe a notice on the > > NiFi Downloads page? > > > > On Tue, Jun 16, 2015 at 11:53 PM, Joe Witt <[email protected]> wrote: > > > > > Ok. I am considering this as a -1 for the notion of 0.3.0 or really > > > 0.x.0. Moved the ticket to 1.0.0. > > > > > > > > > On Tue, Jun 16, 2015 at 11:46 PM, Tony Kurc <[email protected]> wrote: > > > > Joe, > > > > I do not agree that a new jvm is necessarily 'easily addressed', > > > > especially if I've used nifi code or artifacts elsewhere, potentially > > > > integrated into something that has not made the jump to 8. > > > > > > > > I'd be a bit miffed if I saw 'backwards compatible' advertised, then > I > > > drop > > > > a new jar (or nar) in my application, and it barfs. > > > > > > > > > > > > > > > > On Tue, Jun 16, 2015 at 8:38 PM, Joe Witt <[email protected]> > wrote: > > > > > > > >> Tony, > > > >> > > > >> I think this should be 0.x.0 and not 1.0.0 because it is easily > > > >> addressed by operations folks by upgrading their JVM and they > already > > > >> have substantive motivation to do so (no more vulnerability fixes in > > > >> Java 7). We also want to keep our ability to stay close to the > > > >> upgrade cycle of Jetty (a critical dependency of ours) which often > > > >> includes fixes related to security. > > > >> > > > >> I personally see this as a no harm situation. I've wanted to > propose > > > >> this for some time but felt it was too premature because there were > > > >> still updates for Java 7 coming related to security. Now that this > > > >> too has stopped this seems a prudent time to act. > > > >> > > > >> I also acknowledge I'm walking a pretty fine line with my argument > > > >> here. It won't offend me if we do a 1.0.0 release in the near > future > > > >> :-) > > > >> > > > >> Joe > > > >> > > > >> On Tue, Jun 16, 2015 at 11:32 PM, Tony Kurc <[email protected]> > wrote: > > > >> > based on Joey's question, Joe, any reasons you thought this should > > be > > > >> 0.3.0 > > > >> > and not 1.0.0? > > > >> > > > > >> > On Tue, Jun 16, 2015 at 8:21 PM, Joey Echeverria < > [email protected]> > > > >> wrote: > > > >> > > > > >> >> Are we ok with breaking backwards compatibility in minor > releases? > > > >> Updating > > > >> >> the minimum Java version is a breaking change for operational > > teams. > > > >> >> On Tue, Jun 16, 2015 at 19:58 Bobby Owolabi < > > [email protected]> > > > >> >> wrote: > > > >> >> > > > >> >> > +1 > > > >> >> > > > > >> >> > I think this move makes a lot sense. I think Joe’s two > arguments > > > are > > > >> >> very > > > >> >> > strong and some of the new language constructs can open up cool > > > ways > > > >> to > > > >> >> > enhance the developer experience with the framework (hat tip > > Adam). > > > >> >> > > > > >> >> > Bobby > > > >> >> > > > > >> >> > > On Jun 16, 2015, at 10:48 PM, Joe Witt <[email protected]> > > > wrote: > > > >> >> > > > > > >> >> > > Created a JIRA for this: > > > >> >> https://issues.apache.org/jira/browse/NIFI-692 > > > >> >> > > > > > >> >> > > Will keep it up to date if any gotchas come out of this > > > discussion. > > > >> >> > > > > > >> >> > > On Tue, Jun 16, 2015 at 10:42 PM, Adam Taft < > [email protected] > > > > > > >> wrote: > > > >> >> > >> +1 > > > >> >> > >> > > > >> >> > >> The Streams API and new Date API are worthy. Would love to > > > >> >> (eventually) > > > >> >> > >> see a ProcessSession method that can return a > > Stream<FlowFile>. > > > >> >> > >> > > > >> >> > >> > > > >> >> > >> > > > >> >> > >> On Tue, Jun 16, 2015 at 10:24 PM, Joe Witt < > > [email protected]> > > > >> >> wrote: > > > >> >> > >> > > > >> >> > >>> All, > > > >> >> > >>> > > > >> >> > >>> Would like to kick off a discussion for thoughts on moving > > the > > > >> >> minimum > > > >> >> > >>> Java requirement for NiFi to Java 8. There are a two > > immediate > > > >> >> > >>> reasons that make this seem wise: > > > >> >> > >>> > > > >> >> > >>> 1) Java 7 EOL and specifically for security fixes > > > >> >> > >>> https://www.java.com/en/download/faq/java_7.xml > > > >> >> > >>> > > > >> >> > >>> 2) Key dependencies moving to Java8 > > > >> >> > >>> > > > >> https://dev.eclipse.org/mhonarc/lists/jetty-announce/msg00080.html > > > >> >> > >>> > > > >> >> > >>> Now, item 1 does not mean we must move our minimum to Java > 8 > > > but > > > >> item > > > >> >> > >>> 2 does. Java 8 offers some nice language enhancements > which > > > >> could be > > > >> >> > >>> quite useful within the framework. > > > >> >> > >>> > > > >> >> > >>> I propose we make this change happen in NiFi 0.3.x line. > > > >> >> > >>> > > > >> >> > >>> Thanks > > > >> >> > >>> Joe > > > >> >> > >>> > > > >> >> > > > > >> >> > > > > >> >> > > > >> > > > > > >
