Thanks Sean, you captured my concerns pretty well. Another probably bad idea: 0.3.0 operates in two modes - one requires java 8 and you get new jetty, and another in java 7 and you get old jetty.
Not sure if it the right approach, but I put up a stub Roadmap page on Confluence where we can start working on scoping releases and planning a release and versioning schedule ( https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=58851850) On Wed, Jun 17, 2015 at 7:30 AM, Sean Busbey <[email protected]> wrote: > Not to speak for Tony, but here's why I'd list it as a bad idea: > > * additional development branches have a cost. When those branches are long > lived (as a jdk7 would hopefully be) that cost adds up. > * we don't yet have any extant use of compelling java8 features (unless > I've missed a patch that's blocking on this) > > Taken together, these two points indicate, to me, that the support branch > would just be overhead looking to encourage divergence. > > -- > Sean > On Jun 17, 2015 9:19 AM, "Dan Bress" <[email protected]> wrote: > > > Tony, > > Why is "Already having a support branch to continue to support java 7" > > under bad ideas? > > > > Dan Bress > > Software Engineer > > ONYX Consulting Services > > > > ________________________________________ > > From: Tony Kurc <[email protected]> > > Sent: Wednesday, June 17, 2015 10:11 AM > > To: [email protected] > > Subject: Re: Time to move to Java 8 as a minimum > > > > 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 > > > > > >> >> > >>> > > > > > >> >> > > > > > > >> >> > > > > > > >> >> > > > > > >> > > > > > > > > > > > > > > >
