Matt Yeah that is a good summary of it. We want to help the community move NiFi forward along with Java's advances and these major line breaks are the best opportunity to do so. We're in effect making a bet on a given line or set of Java lines for quite some time so we should take advantage of that.
Joe On Mon, Aug 7, 2023 at 5:51 PM Matt Burgess <mattyb...@apache.org> wrote: > That's a fair point and I think represents the way we want to go > forward. If I understand correctly, you're saying bug fixes meant for > both lines shouldn't need/use Java 17 features but new capabilities > for 2.0 should encourage the use of Java 17 features when prudent? > > Thanks, > Matt > > On Mon, Aug 7, 2023 at 8:33 PM Joe Witt <joe.w...@gmail.com> wrote: > > > > The views shared thus far are certainly reasonable but I do want to add > > a different take. > > > > The reason we want to do major releases from time to time is so that we > can > > take advantage of leaps in the language and frameworks we rely on. To > that > > end it would seem unfortunate to not start aggressively taking advantage > of > > that. In particular we've been held to Java 8 standards for at least 7 > > years. I would advocate we allow and even encourage usage of Java 17 > > features/syntax to help move forward. > > > > The point about backporting is important and I agree the 'easiest' way is > > if changes made to main are backportable. Then again we don't really > need > > everything to be backportable and for sure that will start happening less > > and less. If we're talking about 'bug fixes' then it probably makes > sense > > to prefer for now they avoid Java 17 assuming a given fix should target > > both 2.x and 1.x lines. But if we're talking about new features or even > > improvements I think we should be free to move on to Java 17 > > idioms/benefits. If a contrib does this then it just won't go to the 1.x > > line. This atrophy is natural/ok I think and lets us give the 2.x line > the > > attention/growth it deserves. > > > > Thanks > > > > On Mon, Aug 7, 2023 at 2:19 PM David Handermann < > exceptionfact...@apache.org> > > wrote: > > > > > Mike, > > > > > > Thanks for raising the question. Following Matt's comments, I recommend > > > minimizing use of Java 17 features to make it easier to backport > changes > > > for now. > > > > > > Incremental adjustments can be done when backporting, but it requires > the > > > author and reviewer to pay careful attention since the GitHub automated > > > builds for the main branch run on Java 17. > > > > > > As Matt recommended, the alternative is to provide separate pull > requests > > > for the main and support branches. > > > > > > We already have a few Java 11 and 17 references on the main branch for > > > things like List.of(), and most of these are easy to adjust when > > > backporting, but they do require careful attention. > > > > > > Regards, > > > David Handermann > > > > > > On Mon, Aug 7, 2023 at 4:04 PM Matt Burgess <mattyb...@apache.org> > wrote: > > > > > > > In my opinion that's ok, but I think it would be helpful if a PR is > > > > going to be backported to support/nifi-1.x that the PR author > provides > > > > two PRs, one against main with Java 17 features and one against > > > > support/nifi-1.x with Java 8 features. That being said, allowing Java > > > > 17 features may make maintenance tougher while there's an active 1.x > > > > branch. Maybe we should wait until we only support NiFi 2.x? > > > > > > > > On Mon, Aug 7, 2023 at 4:59 PM Mike Thomsen <mikerthom...@gmail.com> > > > > wrote: > > > > > > > > > > Since we're standardizing on 17, we're free and clear to use Java > 17 > > > > > features, right? > > > > > > > >
