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