Joe - For some odd reason, I was reading all about Java release planning and EOL dates and saw some cool communication [1,2]. Usually supported versions overlap. I just wanted to put a strawman up which is why I put 'draft' all over everything.
Also, somewhat related to release planning, this forum for F# user ideas [3,4] made me happy. It has an interesting feedback mechanism. [1] https://blogs.oracle.com/java/entry/java_9_schedule_is_out [2] http://www.infoq.com/news/2015/05/Java-9-On-Track-For-2016 [3] https://fslang.uservoice.com/ [4] https://github.com/Microsoft/visualfsharp/wiki/F%23-4.0-Status On Wed, Jun 17, 2015 at 8:07 PM, Joe Witt <[email protected]> wrote: > Tony, > > I think that is actually a really nice way to communicate it and huge > +1 for actually making a graphic. I would have settled for ascii art > personally but you nailed it with gliffy. We should definitely do > something like this forecasting the next couple of releases and their > purpose. > > What did you want to convey with the overlap in time for 0.x.0 and > 1.0.0? Would you see us doing 0.x.y releases potentially for critical > security items or something for some short period of time as we ramp > up 1.0.0? > > Mike Drob, > > I think for us the semver 0.x.y meaning we get a bit of a mulligan is > probably not fair. We know of significant production use already and > we've made the claim that this thing has been in production for many > years. So we would just be acting a bit lazy to try and use the 0.x.y > thing to make evil changes. In light of the comments of Sean, Tony, > Joey, Bryan I am more of the mind that my proposal was lazy/evil now. > > We should do like Tony proposes and start spitballing when the 1.0.0 > release would be targeted and know that is our next best chance to > clean up deprecated things, move to Java 8 for 'real', etc.. Perhaps > that is what we do after the 0.3.x release. We have a decent set of > tickets already slated for 0.3.x in JIRA and also for 1.0.0. > > Thanks > joe > > On Wed, Jun 17, 2015 at 11:53 AM, Tony Kurc <[email protected]> wrote: > > 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 > >> > > > > >> >> > >>> > >> > > > > >> >> > > >> > > > > >> >> > > >> > > > > >> >> > >> > > > > >> > >> > > > > > >> > > > > >> > > > >> > > >> >
