Something to keep in mind from the semver spec:
1. 2. 3. 4. Major version zero (0.y.z) is for initial development. Anything may change at any time. The public API should not be considered stable. 5. Version 1.0.0 defines the public API. The way in which the version number is incremented after this release is dependent on this public API and how it changes. If we're ready for a full commitment on Public API, then v1.0.0 is fine. However, you have a lot of leeway in the 0.x line to make changes, so maybe Java 8 is still ok for 0.3? Mike On Wed, Jun 17, 2015 at 10:46 AM, Joe Witt <[email protected]> wrote: > My -1 for a support branch would be a super negative :) They have a huge > cost and are a dragging and diverging force for the community. > > There seems to be consensus that this should, as it clearly can, be a 1.0.0 > thing. And we should use discussions like this to better define backward > compatibility definitions and goals. > > Im not bummed at all that this is a bad idea for 0.3.0. > > Thanks > Joe > On Jun 17, 2015 10: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 > > > > > > >> >> > >>> > > > > > > >> >> > > > > > > > >> >> > > > > > > > >> >> > > > > > > >> > > > > > > > > > > > > > > > > > > > > >
