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 >> >> > >>> >> >> > >> >> > >> >> >>
