Thanks for the additional replies, I think the distinction between new features for the next version and bug fixes for both versions is a helpful approach.
Having contributed and backported a number of changes, I have been more focused on compatibility, but I completely agree that we should take advantage of new features on the main branch. We have already started doing this in terms of certain libraries, and more work is in progress. Regards, David Handermann On Mon, Aug 7, 2023 at 7:54 PM Mark Bean <mark.o.b...@gmail.com> wrote: > I was working on a very similar response. Thanks Joe for the clear > articulation. I agree with this approach 100%. > > Adding one additional point, the differentiation of Java 17 in the NiFi 2.0 > line may encourage and expedite the migration to a new major release. I > think we want to get there as soon as possible rather than continue the > burdensome effort of supporting new main lines of code. > > > 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? > > > > > > > > > >
