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