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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > > wrote: > > > > > > Since we're standardizing on 17, we're free and clear to use Java 17 > > > features, right? > > >
