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