[DISCUSS] Finalizing Release Goals for NiFi 2.0

[David Handermann <ex...@apache.org>]

Team,

With the release of NiFi 1.19.0 deprecating support for Java 8, the end of
the year provides a good opportunity for finalizing general release goals
for NiFi 2.0.

Based on previous discussions from July 2021 [1] and June 2022 [2], there
seems to be general agreement with focusing a NiFi 2.0 release on reducing
technical debt while providing a straightforward upgrade path for current
deployments.

I have updated the NiFi 2.0 Proposed Release Goals [3] to reflect more
recent progress in several areas. I also linked the Deprecated Components
and Features [4] page outlining the current state of deprecated
capabilities.

The most recent update to the Proposed Release Goals outlines implementing
migration tooling to make the upgrade process as easy as possible. The
addition of dedicated deprecation logging in NiFi 1.18.0 makes it easier to
warn of breaking changes, but the goal of migration tooling is to make it
easier to upgrade configurations.

The Proposed Release Goals does not include any release timelines right
now, and we should anticipate supporting version 1 for a reasonable period
of time. As more and more libraries deprecate and drop support for Java 8,
it will become increasingly difficult to maintain a support branch, which
is one of the main drivers behind a NiFi 2.0 release that drops support for
Java 8.

The general development strategy should involve transitioning the main
branch to a 2.0.0-SNAPSHOT version so new features and fixes will be
targeted to the new version. Migration tooling will need to be implemented
on a version 1 support branch, and fixes can be backported where possible,
in preparation for subsequent version 1 releases.

With that background, I would like to move to a formal vote soon, changing
the Proposed Release Goals document to Planned Release Goals. Please weigh
the general goals highlighted, and if there are no major roadblocks
identified, I will follow up soon with a vote thread.

Regards,
David Handermann

[1] https://lists.apache.org/thread/yj8scrdbx3pdo7990123mc03q24rn1m7
[2] https://lists.apache.org/thread/mm1xf3b9nvrcgytb92oy3swvvc45fl34
[3]
https://cwiki.apache.org/confluence/display/NIFI/NiFi+2.0+Proposed+Release+Goals
[4]
https://cwiki.apache.org/confluence/display/NIFI/Deprecated+Components+and+Features

Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0

[David Handermann <ex...@apache.org>]

One point of clarification, the following sentence should read Java 17 as a
consideration for the minimum in a subsequent major release:

> It is probably necessary to consider *Java 17* support in a future
version, but Java 11 provides more of a transitional timeline.

Regards,
David Handermann

On Wed, Dec 7, 2022 at 2:00 PM David Handermann <ex...@apache.org>
wrote:

> Thanks to everyone for the feedback thus far!
>
> Regarding making Java 11 the minimum version versus 17, it is a good
> question, particularly in light of the fact that Spring Framework 6 has
> made Java 17 the minimum version as noted. NiFi will not be able to use
> Spring Framework 6 until Java 17 is the minimum version, so that is a key
> concern. One of the key differences in Java 17 is that it enforces
> modularization of access, so access to internal JDK classes log warnings on
> Java 11, but cause failures on Java 17. It is probably necessary to
> consider Java 11 support in a future version, but Java 11 provides more of
> a transitional timeline. With the large number of NiFi dependencies, Java
> 11 seems to provide the broadest level of compatibility for now.
>
> The question of the Jakarta namespace is a good one, particularly as it
> relates to JAXB components. Some of that can be addressed in individual
> modules. Jetty 11 requires the Jakarta namespace, so that should be the
> initial target in absence of any other constraints.
>
> Regarding Controller-Service based configuration, that seems to be a good
> goal in general. This applies to features such as the Proxy Configuration
> Service, versus individual Proxy properties, and would also apply to
> features like MongoDB. This should fall into point 3, removing deprecated
> component properties. InvokeHTTP already has deprecation warnings for those
> properties, and this would be an item where those properties should be
> logged as deprecated in a subsequent version 1 release.
>
> Regards,
> David Handermann
>
> On Wed, Dec 7, 2022 at 1:50 PM ski n <ra...@gmail.com> wrote:
>
>> I read the proposal and seems like a very clear plan. The only thing I
>> noticed:
>>
>> "Spring 6 <https://spring.io/blog/2022/11/16/spring-framework-6-0-goes-ga
>> >
>> removed support for Java 8 in November 2022 "
>>
>> On the release notes of Spring Framework 6.0 it says:
>>
>> " As a major revision of the core framework, Spring Framework 6.0 comes
>> with a Java 17+ baseline and a move to Jakarta EE 9+ "
>>
>> When JDK 11 is the baseline for NiFi, can it use Spring Framework 6.0?
>>
>> And on Jakarta EE 9+, I see a lot of projects now switching from Javax to
>> Jakarta (for example Camel:
>> https://issues.apache.org/jira/browse/CAMEL-14680)
>>
>> What will NiFi do with Jakarta namespace?
>>
>> Raymond
>>
>>
>>
>>
>> On Wed, Dec 7, 2022 at 8:20 PM Mark Bean <ma...@gmail.com> wrote:
>>
>> > I agree this is a great start to a discussion with pointers to important
>> > docs for the 2.0 transition. Thanks David!
>> >
>> > Mike - what do you mean by "controller service-based configuration for
>> > connection details"?
>> >
>> > Also, the transition from Java 11 to 17 is not without potential issues.
>> > I've discovered one already. [1] I support stepping up on Java version
>> > requirements. Perhaps rather than the currently stated "Requires Java 8
>> or
>> > Java 11", the requirement can be "Requires Java 11 or Java 17". I don't
>> > think you were suggesting the minimum version be Java 17, were you?
>> Either
>> > way, the issue with Java 17 needs to be identified and fixed as well as
>> > more thorough testing to find other possible edge cases before we move
>> > forward too aggressively.
>> >
>> > [1] https://issues.apache.org/jira/browse/NIFI-10958
>> >
>> > On Wed, Dec 7, 2022 at 1:33 PM Mike Thomsen <mi...@gmail.com>
>> > wrote:
>> >
>> > > Really good start on the discussion. One thing I'm curious about is
>> > > Java 11 vs 17. Java 8 -> 11 is major jump that I can understand why
>> > > businesses scoffed at that for a long time, but the lift from 11 to 17
>> > > was about like 7 -> 8. A 2.0 release seems like a good time to jump
>> > > straight to the latest official LTS for Java and start greenlighting
>> > > new language features that might simplify things.
>> > >
>> > > I would also add (since I didn't see it) a design goal of forcing a
>> > > complete shift in all bundles to using controller service-based
>> > > configurations for connection details. 2.0 feels like a really good
>> > > time for us to establish a community-wide best practice of
>> > > centralizing configurations in dedicated components.
>> > >
>> > > On Wed, Dec 7, 2022 at 9:13 AM Mark Payne <ma...@hotmail.com>
>> wrote:
>> > > >
>> > > > Yeah, agreed. I am very supportive, as well.
>> > > >
>> > > > Thanks for taking the time to put this together, David.
>> > > >
>> > > > -Mark
>> > > >
>> > > >
>> > > > > On Dec 7, 2022, at 4:07 AM, Pierre Villard <
>> > > pierre.villard.fr@gmail.com> wrote:
>> > > > >
>> > > > > Thanks for putting this together David. This is an excellent
>> writeup
>> > > and
>> > > > > it's great to have a release where we focus on tech debt as well
>> as
>> > > making
>> > > > > sure we stay up to date with our dependencies and what we support.
>> > > This is
>> > > > > a great opportunity for us to clean a lot of things in our code
>> and I
>> > > can't
>> > > > > wait for us to get started with this. I'm definitely a +1 to have
>> a
>> > > formal
>> > > > > vote on this proposal.
>> > > > >
>> > > > > Thanks,
>> > > > > Pierre
>> > > > >
>> > > > > Le mar. 6 déc. 2022 à 23:50, Joe Witt <jo...@gmail.com> a
>> écrit :
>> > > > >
>> > > > >> David, All,
>> > > > >>
>> > > > >> This is an excellent writeup/good framing.  I am supportive of
>> this
>> > > > >> as-is since it is achievable and lays out a clear path.  We can
>> make
>> > > > >> milestone releases of NiFi 2.0.0 along the way until we achieve
>> all
>> > > > >> the stated goals. I assume migration bits will be the long pole
>> and
>> > > > >> once we have them sorted we can kick out a 2.0.0.   We already
>> have
>> > a
>> > > > >> version guide that governs how long we'd keep 1.x maintained
>> though
>> > > > >> the phase out is pretty natural as we move main to a 2.0.0 basis
>> > > > >> anyway.
>> > > > >>
>> > > > >> Not to confuse this thread but it makes me think we could do a
>> > similar
>> > > > >> framing for a NiFi 3.0 which lays out a potentially new approach
>> to
>> > > > >> NiFi decoupling the web/interface from the runtime/operations and
>> > one
>> > > > >> which is more fundamentally K8S based.  But we can cross that
>> > bridge a
>> > > > >> bit later.  Does seem more and more like folks in the community
>> > would
>> > > > >> like to know more about the potential directions we can go.
>> > > > >>
>> > > > >> Thanks!
>> > > > >> Joe
>> > > > >>
>> > > > >> On Tue, Dec 6, 2022 at 1:53 PM David Handermann
>> > > > >> <ex...@apache.org> wrote:
>> > > > >>>
>> > > > >>> Team,
>> > > > >>>
>> > > > >>> With the release of NiFi 1.19.0 deprecating support for Java 8,
>> the
>> > > end
>> > > > >> of
>> > > > >>> the year provides a good opportunity for finalizing general
>> release
>> > > goals
>> > > > >>> for NiFi 2.0.
>> > > > >>>
>> > > > >>> Based on previous discussions from July 2021 [1] and June 2022
>> [2],
>> > > there
>> > > > >>> seems to be general agreement with focusing a NiFi 2.0 release
>> on
>> > > > >> reducing
>> > > > >>> technical debt while providing a straightforward upgrade path
>> for
>> > > current
>> > > > >>> deployments.
>> > > > >>>
>> > > > >>> I have updated the NiFi 2.0 Proposed Release Goals [3] to
>> reflect
>> > > more
>> > > > >>> recent progress in several areas. I also linked the Deprecated
>> > > Components
>> > > > >>> and Features [4] page outlining the current state of deprecated
>> > > > >>> capabilities.
>> > > > >>>
>> > > > >>> The most recent update to the Proposed Release Goals outlines
>> > > > >> implementing
>> > > > >>> migration tooling to make the upgrade process as easy as
>> possible.
>> > > The
>> > > > >>> addition of dedicated deprecation logging in NiFi 1.18.0 makes
>> it
>> > > easier
>> > > > >> to
>> > > > >>> warn of breaking changes, but the goal of migration tooling is
>> to
>> > > make it
>> > > > >>> easier to upgrade configurations.
>> > > > >>>
>> > > > >>> The Proposed Release Goals does not include any release
>> timelines
>> > > right
>> > > > >>> now, and we should anticipate supporting version 1 for a
>> reasonable
>> > > > >> period
>> > > > >>> of time. As more and more libraries deprecate and drop support
>> for
>> > > Java
>> > > > >> 8,
>> > > > >>> it will become increasingly difficult to maintain a support
>> branch,
>> > > which
>> > > > >>> is one of the main drivers behind a NiFi 2.0 release that drops
>> > > support
>> > > > >> for
>> > > > >>> Java 8.
>> > > > >>>
>> > > > >>> The general development strategy should involve transitioning
>> the
>> > > main
>> > > > >>> branch to a 2.0.0-SNAPSHOT version so new features and fixes
>> will
>> > be
>> > > > >>> targeted to the new version. Migration tooling will need to be
>> > > > >> implemented
>> > > > >>> on a version 1 support branch, and fixes can be backported where
>> > > > >> possible,
>> > > > >>> in preparation for subsequent version 1 releases.
>> > > > >>>
>> > > > >>> With that background, I would like to move to a formal vote
>> soon,
>> > > > >> changing
>> > > > >>> the Proposed Release Goals document to Planned Release Goals.
>> > Please
>> > > > >> weigh
>> > > > >>> the general goals highlighted, and if there are no major
>> roadblocks
>> > > > >>> identified, I will follow up soon with a vote thread.
>> > > > >>>
>> > > > >>> Regards,
>> > > > >>> David Handermann
>> > > > >>>
>> > > > >>> [1]
>> > https://lists.apache.org/thread/yj8scrdbx3pdo7990123mc03q24rn1m7
>> > > > >>> [2]
>> > https://lists.apache.org/thread/mm1xf3b9nvrcgytb92oy3swvvc45fl34
>> > > > >>> [3]
>> > > > >>>
>> > > > >>
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/NIFI/NiFi+2.0+Proposed+Release+Goals
>> > > > >>> [4]
>> > > > >>>
>> > > > >>
>> > >
>> >
>> https://cwiki.apache.org/confluence/display/NIFI/Deprecated+Components+and+Features
>> > > > >>
>> > > >
>> > >
>> >
>>
>

Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0

[David Handermann <ex...@apache.org>]

Thanks to everyone for the feedback thus far!

Regarding making Java 11 the minimum version versus 17, it is a good
question, particularly in light of the fact that Spring Framework 6 has
made Java 17 the minimum version as noted. NiFi will not be able to use
Spring Framework 6 until Java 17 is the minimum version, so that is a key
concern. One of the key differences in Java 17 is that it enforces
modularization of access, so access to internal JDK classes log warnings on
Java 11, but cause failures on Java 17. It is probably necessary to
consider Java 11 support in a future version, but Java 11 provides more of
a transitional timeline. With the large number of NiFi dependencies, Java
11 seems to provide the broadest level of compatibility for now.

The question of the Jakarta namespace is a good one, particularly as it
relates to JAXB components. Some of that can be addressed in individual
modules. Jetty 11 requires the Jakarta namespace, so that should be the
initial target in absence of any other constraints.

Regarding Controller-Service based configuration, that seems to be a good
goal in general. This applies to features such as the Proxy Configuration
Service, versus individual Proxy properties, and would also apply to
features like MongoDB. This should fall into point 3, removing deprecated
component properties. InvokeHTTP already has deprecation warnings for those
properties, and this would be an item where those properties should be
logged as deprecated in a subsequent version 1 release.

Regards,
David Handermann

On Wed, Dec 7, 2022 at 1:50 PM ski n <ra...@gmail.com> wrote:

> I read the proposal and seems like a very clear plan. The only thing I
> noticed:
>
> "Spring 6 <https://spring.io/blog/2022/11/16/spring-framework-6-0-goes-ga>
> removed support for Java 8 in November 2022 "
>
> On the release notes of Spring Framework 6.0 it says:
>
> " As a major revision of the core framework, Spring Framework 6.0 comes
> with a Java 17+ baseline and a move to Jakarta EE 9+ "
>
> When JDK 11 is the baseline for NiFi, can it use Spring Framework 6.0?
>
> And on Jakarta EE 9+, I see a lot of projects now switching from Javax to
> Jakarta (for example Camel:
> https://issues.apache.org/jira/browse/CAMEL-14680)
>
> What will NiFi do with Jakarta namespace?
>
> Raymond
>
>
>
>
> On Wed, Dec 7, 2022 at 8:20 PM Mark Bean <ma...@gmail.com> wrote:
>
> > I agree this is a great start to a discussion with pointers to important
> > docs for the 2.0 transition. Thanks David!
> >
> > Mike - what do you mean by "controller service-based configuration for
> > connection details"?
> >
> > Also, the transition from Java 11 to 17 is not without potential issues.
> > I've discovered one already. [1] I support stepping up on Java version
> > requirements. Perhaps rather than the currently stated "Requires Java 8
> or
> > Java 11", the requirement can be "Requires Java 11 or Java 17". I don't
> > think you were suggesting the minimum version be Java 17, were you?
> Either
> > way, the issue with Java 17 needs to be identified and fixed as well as
> > more thorough testing to find other possible edge cases before we move
> > forward too aggressively.
> >
> > [1] https://issues.apache.org/jira/browse/NIFI-10958
> >
> > On Wed, Dec 7, 2022 at 1:33 PM Mike Thomsen <mi...@gmail.com>
> > wrote:
> >
> > > Really good start on the discussion. One thing I'm curious about is
> > > Java 11 vs 17. Java 8 -> 11 is major jump that I can understand why
> > > businesses scoffed at that for a long time, but the lift from 11 to 17
> > > was about like 7 -> 8. A 2.0 release seems like a good time to jump
> > > straight to the latest official LTS for Java and start greenlighting
> > > new language features that might simplify things.
> > >
> > > I would also add (since I didn't see it) a design goal of forcing a
> > > complete shift in all bundles to using controller service-based
> > > configurations for connection details. 2.0 feels like a really good
> > > time for us to establish a community-wide best practice of
> > > centralizing configurations in dedicated components.
> > >
> > > On Wed, Dec 7, 2022 at 9:13 AM Mark Payne <ma...@hotmail.com>
> wrote:
> > > >
> > > > Yeah, agreed. I am very supportive, as well.
> > > >
> > > > Thanks for taking the time to put this together, David.
> > > >
> > > > -Mark
> > > >
> > > >
> > > > > On Dec 7, 2022, at 4:07 AM, Pierre Villard <
> > > pierre.villard.fr@gmail.com> wrote:
> > > > >
> > > > > Thanks for putting this together David. This is an excellent
> writeup
> > > and
> > > > > it's great to have a release where we focus on tech debt as well as
> > > making
> > > > > sure we stay up to date with our dependencies and what we support.
> > > This is
> > > > > a great opportunity for us to clean a lot of things in our code
> and I
> > > can't
> > > > > wait for us to get started with this. I'm definitely a +1 to have a
> > > formal
> > > > > vote on this proposal.
> > > > >
> > > > > Thanks,
> > > > > Pierre
> > > > >
> > > > > Le mar. 6 déc. 2022 à 23:50, Joe Witt <jo...@gmail.com> a
> écrit :
> > > > >
> > > > >> David, All,
> > > > >>
> > > > >> This is an excellent writeup/good framing.  I am supportive of
> this
> > > > >> as-is since it is achievable and lays out a clear path.  We can
> make
> > > > >> milestone releases of NiFi 2.0.0 along the way until we achieve
> all
> > > > >> the stated goals. I assume migration bits will be the long pole
> and
> > > > >> once we have them sorted we can kick out a 2.0.0.   We already
> have
> > a
> > > > >> version guide that governs how long we'd keep 1.x maintained
> though
> > > > >> the phase out is pretty natural as we move main to a 2.0.0 basis
> > > > >> anyway.
> > > > >>
> > > > >> Not to confuse this thread but it makes me think we could do a
> > similar
> > > > >> framing for a NiFi 3.0 which lays out a potentially new approach
> to
> > > > >> NiFi decoupling the web/interface from the runtime/operations and
> > one
> > > > >> which is more fundamentally K8S based.  But we can cross that
> > bridge a
> > > > >> bit later.  Does seem more and more like folks in the community
> > would
> > > > >> like to know more about the potential directions we can go.
> > > > >>
> > > > >> Thanks!
> > > > >> Joe
> > > > >>
> > > > >> On Tue, Dec 6, 2022 at 1:53 PM David Handermann
> > > > >> <ex...@apache.org> wrote:
> > > > >>>
> > > > >>> Team,
> > > > >>>
> > > > >>> With the release of NiFi 1.19.0 deprecating support for Java 8,
> the
> > > end
> > > > >> of
> > > > >>> the year provides a good opportunity for finalizing general
> release
> > > goals
> > > > >>> for NiFi 2.0.
> > > > >>>
> > > > >>> Based on previous discussions from July 2021 [1] and June 2022
> [2],
> > > there
> > > > >>> seems to be general agreement with focusing a NiFi 2.0 release on
> > > > >> reducing
> > > > >>> technical debt while providing a straightforward upgrade path for
> > > current
> > > > >>> deployments.
> > > > >>>
> > > > >>> I have updated the NiFi 2.0 Proposed Release Goals [3] to reflect
> > > more
> > > > >>> recent progress in several areas. I also linked the Deprecated
> > > Components
> > > > >>> and Features [4] page outlining the current state of deprecated
> > > > >>> capabilities.
> > > > >>>
> > > > >>> The most recent update to the Proposed Release Goals outlines
> > > > >> implementing
> > > > >>> migration tooling to make the upgrade process as easy as
> possible.
> > > The
> > > > >>> addition of dedicated deprecation logging in NiFi 1.18.0 makes it
> > > easier
> > > > >> to
> > > > >>> warn of breaking changes, but the goal of migration tooling is to
> > > make it
> > > > >>> easier to upgrade configurations.
> > > > >>>
> > > > >>> The Proposed Release Goals does not include any release timelines
> > > right
> > > > >>> now, and we should anticipate supporting version 1 for a
> reasonable
> > > > >> period
> > > > >>> of time. As more and more libraries deprecate and drop support
> for
> > > Java
> > > > >> 8,
> > > > >>> it will become increasingly difficult to maintain a support
> branch,
> > > which
> > > > >>> is one of the main drivers behind a NiFi 2.0 release that drops
> > > support
> > > > >> for
> > > > >>> Java 8.
> > > > >>>
> > > > >>> The general development strategy should involve transitioning the
> > > main
> > > > >>> branch to a 2.0.0-SNAPSHOT version so new features and fixes will
> > be
> > > > >>> targeted to the new version. Migration tooling will need to be
> > > > >> implemented
> > > > >>> on a version 1 support branch, and fixes can be backported where
> > > > >> possible,
> > > > >>> in preparation for subsequent version 1 releases.
> > > > >>>
> > > > >>> With that background, I would like to move to a formal vote soon,
> > > > >> changing
> > > > >>> the Proposed Release Goals document to Planned Release Goals.
> > Please
> > > > >> weigh
> > > > >>> the general goals highlighted, and if there are no major
> roadblocks
> > > > >>> identified, I will follow up soon with a vote thread.
> > > > >>>
> > > > >>> Regards,
> > > > >>> David Handermann
> > > > >>>
> > > > >>> [1]
> > https://lists.apache.org/thread/yj8scrdbx3pdo7990123mc03q24rn1m7
> > > > >>> [2]
> > https://lists.apache.org/thread/mm1xf3b9nvrcgytb92oy3swvvc45fl34
> > > > >>> [3]
> > > > >>>
> > > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/NIFI/NiFi+2.0+Proposed+Release+Goals
> > > > >>> [4]
> > > > >>>
> > > > >>
> > >
> >
> https://cwiki.apache.org/confluence/display/NIFI/Deprecated+Components+and+Features
> > > > >>
> > > >
> > >
> >
>

Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0

[ski n <ra...@gmail.com>]

I read the proposal and seems like a very clear plan. The only thing I
noticed:

"Spring 6 <https://spring.io/blog/2022/11/16/spring-framework-6-0-goes-ga>
removed support for Java 8 in November 2022 "

On the release notes of Spring Framework 6.0 it says:

" As a major revision of the core framework, Spring Framework 6.0 comes
with a Java 17+ baseline and a move to Jakarta EE 9+ "

When JDK 11 is the baseline for NiFi, can it use Spring Framework 6.0?

And on Jakarta EE 9+, I see a lot of projects now switching from Javax to
Jakarta (for example Camel:
https://issues.apache.org/jira/browse/CAMEL-14680)

What will NiFi do with Jakarta namespace?

Raymond




On Wed, Dec 7, 2022 at 8:20 PM Mark Bean <ma...@gmail.com> wrote:

> I agree this is a great start to a discussion with pointers to important
> docs for the 2.0 transition. Thanks David!
>
> Mike - what do you mean by "controller service-based configuration for
> connection details"?
>
> Also, the transition from Java 11 to 17 is not without potential issues.
> I've discovered one already. [1] I support stepping up on Java version
> requirements. Perhaps rather than the currently stated "Requires Java 8 or
> Java 11", the requirement can be "Requires Java 11 or Java 17". I don't
> think you were suggesting the minimum version be Java 17, were you? Either
> way, the issue with Java 17 needs to be identified and fixed as well as
> more thorough testing to find other possible edge cases before we move
> forward too aggressively.
>
> [1] https://issues.apache.org/jira/browse/NIFI-10958
>
> On Wed, Dec 7, 2022 at 1:33 PM Mike Thomsen <mi...@gmail.com>
> wrote:
>
> > Really good start on the discussion. One thing I'm curious about is
> > Java 11 vs 17. Java 8 -> 11 is major jump that I can understand why
> > businesses scoffed at that for a long time, but the lift from 11 to 17
> > was about like 7 -> 8. A 2.0 release seems like a good time to jump
> > straight to the latest official LTS for Java and start greenlighting
> > new language features that might simplify things.
> >
> > I would also add (since I didn't see it) a design goal of forcing a
> > complete shift in all bundles to using controller service-based
> > configurations for connection details. 2.0 feels like a really good
> > time for us to establish a community-wide best practice of
> > centralizing configurations in dedicated components.
> >
> > On Wed, Dec 7, 2022 at 9:13 AM Mark Payne <ma...@hotmail.com> wrote:
> > >
> > > Yeah, agreed. I am very supportive, as well.
> > >
> > > Thanks for taking the time to put this together, David.
> > >
> > > -Mark
> > >
> > >
> > > > On Dec 7, 2022, at 4:07 AM, Pierre Villard <
> > pierre.villard.fr@gmail.com> wrote:
> > > >
> > > > Thanks for putting this together David. This is an excellent writeup
> > and
> > > > it's great to have a release where we focus on tech debt as well as
> > making
> > > > sure we stay up to date with our dependencies and what we support.
> > This is
> > > > a great opportunity for us to clean a lot of things in our code and I
> > can't
> > > > wait for us to get started with this. I'm definitely a +1 to have a
> > formal
> > > > vote on this proposal.
> > > >
> > > > Thanks,
> > > > Pierre
> > > >
> > > > Le mar. 6 déc. 2022 à 23:50, Joe Witt <jo...@gmail.com> a écrit :
> > > >
> > > >> David, All,
> > > >>
> > > >> This is an excellent writeup/good framing.  I am supportive of this
> > > >> as-is since it is achievable and lays out a clear path.  We can make
> > > >> milestone releases of NiFi 2.0.0 along the way until we achieve all
> > > >> the stated goals. I assume migration bits will be the long pole and
> > > >> once we have them sorted we can kick out a 2.0.0.   We already have
> a
> > > >> version guide that governs how long we'd keep 1.x maintained though
> > > >> the phase out is pretty natural as we move main to a 2.0.0 basis
> > > >> anyway.
> > > >>
> > > >> Not to confuse this thread but it makes me think we could do a
> similar
> > > >> framing for a NiFi 3.0 which lays out a potentially new approach to
> > > >> NiFi decoupling the web/interface from the runtime/operations and
> one
> > > >> which is more fundamentally K8S based.  But we can cross that
> bridge a
> > > >> bit later.  Does seem more and more like folks in the community
> would
> > > >> like to know more about the potential directions we can go.
> > > >>
> > > >> Thanks!
> > > >> Joe
> > > >>
> > > >> On Tue, Dec 6, 2022 at 1:53 PM David Handermann
> > > >> <ex...@apache.org> wrote:
> > > >>>
> > > >>> Team,
> > > >>>
> > > >>> With the release of NiFi 1.19.0 deprecating support for Java 8, the
> > end
> > > >> of
> > > >>> the year provides a good opportunity for finalizing general release
> > goals
> > > >>> for NiFi 2.0.
> > > >>>
> > > >>> Based on previous discussions from July 2021 [1] and June 2022 [2],
> > there
> > > >>> seems to be general agreement with focusing a NiFi 2.0 release on
> > > >> reducing
> > > >>> technical debt while providing a straightforward upgrade path for
> > current
> > > >>> deployments.
> > > >>>
> > > >>> I have updated the NiFi 2.0 Proposed Release Goals [3] to reflect
> > more
> > > >>> recent progress in several areas. I also linked the Deprecated
> > Components
> > > >>> and Features [4] page outlining the current state of deprecated
> > > >>> capabilities.
> > > >>>
> > > >>> The most recent update to the Proposed Release Goals outlines
> > > >> implementing
> > > >>> migration tooling to make the upgrade process as easy as possible.
> > The
> > > >>> addition of dedicated deprecation logging in NiFi 1.18.0 makes it
> > easier
> > > >> to
> > > >>> warn of breaking changes, but the goal of migration tooling is to
> > make it
> > > >>> easier to upgrade configurations.
> > > >>>
> > > >>> The Proposed Release Goals does not include any release timelines
> > right
> > > >>> now, and we should anticipate supporting version 1 for a reasonable
> > > >> period
> > > >>> of time. As more and more libraries deprecate and drop support for
> > Java
> > > >> 8,
> > > >>> it will become increasingly difficult to maintain a support branch,
> > which
> > > >>> is one of the main drivers behind a NiFi 2.0 release that drops
> > support
> > > >> for
> > > >>> Java 8.
> > > >>>
> > > >>> The general development strategy should involve transitioning the
> > main
> > > >>> branch to a 2.0.0-SNAPSHOT version so new features and fixes will
> be
> > > >>> targeted to the new version. Migration tooling will need to be
> > > >> implemented
> > > >>> on a version 1 support branch, and fixes can be backported where
> > > >> possible,
> > > >>> in preparation for subsequent version 1 releases.
> > > >>>
> > > >>> With that background, I would like to move to a formal vote soon,
> > > >> changing
> > > >>> the Proposed Release Goals document to Planned Release Goals.
> Please
> > > >> weigh
> > > >>> the general goals highlighted, and if there are no major roadblocks
> > > >>> identified, I will follow up soon with a vote thread.
> > > >>>
> > > >>> Regards,
> > > >>> David Handermann
> > > >>>
> > > >>> [1]
> https://lists.apache.org/thread/yj8scrdbx3pdo7990123mc03q24rn1m7
> > > >>> [2]
> https://lists.apache.org/thread/mm1xf3b9nvrcgytb92oy3swvvc45fl34
> > > >>> [3]
> > > >>>
> > > >>
> >
> https://cwiki.apache.org/confluence/display/NIFI/NiFi+2.0+Proposed+Release+Goals
> > > >>> [4]
> > > >>>
> > > >>
> >
> https://cwiki.apache.org/confluence/display/NIFI/Deprecated+Components+and+Features
> > > >>
> > >
> >
>

Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0

[Bryan Bende <bb...@gmail.com>]

Hello,

The purpose of displayName is to allow changing the name shown in the
UI without breaking existing flows, meaning it still uses the original
name behind the scenes in flow xml/json, but just shows a different
name in the UI, so the primary purpose is for them to be different.

Since it was hard to know what the real name was, a recent release
added a new column in the documentation called "API Name". Example for
ConsumeKafka_2_6 processor:
https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-kafka-2-6-nar/1.19.1/org.apache.nifi.processors.kafka.pubsub.ConsumeKafka_2_6/index.html

Thanks,

Bryan

On Mon, Dec 12, 2022 at 1:21 PM Mathew Kiprop <ma...@gmail.com> wrote:
>
> Hello all,
>
> I hope this is the right thread to raise this.
> I have recently been working with nipyapi[1] creating flows and found
> challenge when configuring components(processors/CS) properties whose
> PropertyDescriptor$displayName is different than PropertyDescriptor$name.
> I had to use browser inspection tools to see how the request is submitted
> by NiFi fronted,  alternatively checking the name in the source code.
>
> Moving to 2.0, would it be good to standardize on PropertyDescriptor$name
> and displayname?
>
> Thanks,
> Mathew.
> [1] https://github.com/Chaffelson/nipyapi
>
> On Mon, 12 Dec 2022 at 19:46, David Handermann <ex...@apache.org>
> wrote:
>
> > Hi Isha,
> >
> > As the scope of the proposed release goals does not include changing the
> > Site-to-Site protocol, that setup should work. Any kind of breaking
> > compatibility changes will need to be documented, but the general goal is
> > to make the upgrade as seamless as possible to encourage adoption.
> >
> > Regards,
> > David Handermann
> >
> > On Mon, Dec 12, 2022 at 4:12 AM Isha Lamboo <
> > isha.lamboo@virtualsciences.nl>
> > wrote:
> >
> > > Hi all,
> > >
> > > This may be too basic/self-explanatory to count as a goal at all, but
> > will
> > > site-to-site interoperability between NiFi 1.x and NiFi 2.x nodes will be
> > > preserved?
> > >
> > > Regards,
> > >
> > > Isha
> > >
> > > -----Oorspronkelijk bericht-----
> > > Van: David Handermann <ex...@apache.org>
> > > Verzonden: zondag 11 december 2022 04:08
> > > Aan: Otto Fowler <ot...@gmail.com>
> > > CC: dev@nifi.apache.org
> > > Onderwerp: Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0
> > >
> > > Hi Otto,
> > >
> > > Thanks for the reply, that is a good question.
> > >
> > > There is certainly a need to maintain the current version 1 branch for
> > > some amount of time, but the exact amount of time will need to be
> > > determined.
> > >
> > > Point 10 of the Proposed Release Goals includes implementing migration
> > > tools, which will have to be implemented in subsequent version 1
> > releases,
> > > so support for version 1 would not go away any time soon. It will become
> > > more difficult to maintain libraries as time goes on, but we should also
> > > identify some strategies for subsequent maintenance releases.
> > >
> > > I anticipate the need for future votes to sunset version 1, but that
> > > should not occur until there has been significant work on version 2 and
> > > associated migration tools, with documentation.
> > >
> > > The main purpose of the 2.0 Proposed Release Goals is to focus that
> > scope,
> > > and as you noted, we should give some parallel consideration to scoping
> > for
> > > version 1 releases.
> > >
> > > Regards,
> > > David Handermann
> > >
> > > On Sat, Dec 10, 2022 at 8:42 PM Otto Fowler <ot...@gmail.com>
> > > wrote:
> > >
> > > > Sorry to be late to this, the goals seem great. The question that
> > > > comes to my mind is will the current 1.x line will be maintained?
> > > >
> > > > That may be a parallel issue to the goals, but it is important if we
> > > > are dropping support for Java versions.
> > > >
> > > > I would think that *some* position on that has to be decided and
> > > > communicated ( if not voted on ).
> > > >
> > > >
> > >
> >

Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0

[Mathew Kiprop <ma...@gmail.com>]

Hello all,

I hope this is the right thread to raise this.
I have recently been working with nipyapi[1] creating flows and found
challenge when configuring components(processors/CS) properties whose
PropertyDescriptor$displayName is different than PropertyDescriptor$name.
I had to use browser inspection tools to see how the request is submitted
by NiFi fronted,  alternatively checking the name in the source code.

Moving to 2.0, would it be good to standardize on PropertyDescriptor$name
and displayname?

Thanks,
Mathew.
[1] https://github.com/Chaffelson/nipyapi

On Mon, 12 Dec 2022 at 19:46, David Handermann <ex...@apache.org>
wrote:

> Hi Isha,
>
> As the scope of the proposed release goals does not include changing the
> Site-to-Site protocol, that setup should work. Any kind of breaking
> compatibility changes will need to be documented, but the general goal is
> to make the upgrade as seamless as possible to encourage adoption.
>
> Regards,
> David Handermann
>
> On Mon, Dec 12, 2022 at 4:12 AM Isha Lamboo <
> isha.lamboo@virtualsciences.nl>
> wrote:
>
> > Hi all,
> >
> > This may be too basic/self-explanatory to count as a goal at all, but
> will
> > site-to-site interoperability between NiFi 1.x and NiFi 2.x nodes will be
> > preserved?
> >
> > Regards,
> >
> > Isha
> >
> > -----Oorspronkelijk bericht-----
> > Van: David Handermann <ex...@apache.org>
> > Verzonden: zondag 11 december 2022 04:08
> > Aan: Otto Fowler <ot...@gmail.com>
> > CC: dev@nifi.apache.org
> > Onderwerp: Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0
> >
> > Hi Otto,
> >
> > Thanks for the reply, that is a good question.
> >
> > There is certainly a need to maintain the current version 1 branch for
> > some amount of time, but the exact amount of time will need to be
> > determined.
> >
> > Point 10 of the Proposed Release Goals includes implementing migration
> > tools, which will have to be implemented in subsequent version 1
> releases,
> > so support for version 1 would not go away any time soon. It will become
> > more difficult to maintain libraries as time goes on, but we should also
> > identify some strategies for subsequent maintenance releases.
> >
> > I anticipate the need for future votes to sunset version 1, but that
> > should not occur until there has been significant work on version 2 and
> > associated migration tools, with documentation.
> >
> > The main purpose of the 2.0 Proposed Release Goals is to focus that
> scope,
> > and as you noted, we should give some parallel consideration to scoping
> for
> > version 1 releases.
> >
> > Regards,
> > David Handermann
> >
> > On Sat, Dec 10, 2022 at 8:42 PM Otto Fowler <ot...@gmail.com>
> > wrote:
> >
> > > Sorry to be late to this, the goals seem great. The question that
> > > comes to my mind is will the current 1.x line will be maintained?
> > >
> > > That may be a parallel issue to the goals, but it is important if we
> > > are dropping support for Java versions.
> > >
> > > I would think that *some* position on that has to be decided and
> > > communicated ( if not voted on ).
> > >
> > >
> >
>

Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0

[David Handermann <ex...@apache.org>]

Hi Isha,

As the scope of the proposed release goals does not include changing the
Site-to-Site protocol, that setup should work. Any kind of breaking
compatibility changes will need to be documented, but the general goal is
to make the upgrade as seamless as possible to encourage adoption.

Regards,
David Handermann

On Mon, Dec 12, 2022 at 4:12 AM Isha Lamboo <is...@virtualsciences.nl>
wrote:

> Hi all,
>
> This may be too basic/self-explanatory to count as a goal at all, but will
> site-to-site interoperability between NiFi 1.x and NiFi 2.x nodes will be
> preserved?
>
> Regards,
>
> Isha
>
> -----Oorspronkelijk bericht-----
> Van: David Handermann <ex...@apache.org>
> Verzonden: zondag 11 december 2022 04:08
> Aan: Otto Fowler <ot...@gmail.com>
> CC: dev@nifi.apache.org
> Onderwerp: Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0
>
> Hi Otto,
>
> Thanks for the reply, that is a good question.
>
> There is certainly a need to maintain the current version 1 branch for
> some amount of time, but the exact amount of time will need to be
> determined.
>
> Point 10 of the Proposed Release Goals includes implementing migration
> tools, which will have to be implemented in subsequent version 1 releases,
> so support for version 1 would not go away any time soon. It will become
> more difficult to maintain libraries as time goes on, but we should also
> identify some strategies for subsequent maintenance releases.
>
> I anticipate the need for future votes to sunset version 1, but that
> should not occur until there has been significant work on version 2 and
> associated migration tools, with documentation.
>
> The main purpose of the 2.0 Proposed Release Goals is to focus that scope,
> and as you noted, we should give some parallel consideration to scoping for
> version 1 releases.
>
> Regards,
> David Handermann
>
> On Sat, Dec 10, 2022 at 8:42 PM Otto Fowler <ot...@gmail.com>
> wrote:
>
> > Sorry to be late to this, the goals seem great. The question that
> > comes to my mind is will the current 1.x line will be maintained?
> >
> > That may be a parallel issue to the goals, but it is important if we
> > are dropping support for Java versions.
> >
> > I would think that *some* position on that has to be decided and
> > communicated ( if not voted on ).
> >
> >
>

RE: [DISCUSS] Finalizing Release Goals for NiFi 2.0

[Isha Lamboo <is...@virtualsciences.nl>]

Hi all,

This may be too basic/self-explanatory to count as a goal at all, but will site-to-site interoperability between NiFi 1.x and NiFi 2.x nodes will be preserved?

Regards,

Isha

-----Oorspronkelijk bericht-----
Van: David Handermann <ex...@apache.org> 
Verzonden: zondag 11 december 2022 04:08
Aan: Otto Fowler <ot...@gmail.com>
CC: dev@nifi.apache.org
Onderwerp: Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0

Hi Otto,

Thanks for the reply, that is a good question.

There is certainly a need to maintain the current version 1 branch for some amount of time, but the exact amount of time will need to be determined.

Point 10 of the Proposed Release Goals includes implementing migration tools, which will have to be implemented in subsequent version 1 releases, so support for version 1 would not go away any time soon. It will become more difficult to maintain libraries as time goes on, but we should also identify some strategies for subsequent maintenance releases.

I anticipate the need for future votes to sunset version 1, but that should not occur until there has been significant work on version 2 and associated migration tools, with documentation.

The main purpose of the 2.0 Proposed Release Goals is to focus that scope, and as you noted, we should give some parallel consideration to scoping for version 1 releases.

Regards,
David Handermann

On Sat, Dec 10, 2022 at 8:42 PM Otto Fowler <ot...@gmail.com> wrote:

> Sorry to be late to this, the goals seem great. The question that 
> comes to my mind is will the current 1.x line will be maintained?
>
> That may be a parallel issue to the goals, but it is important if we 
> are dropping support for Java versions.
>
> I would think that *some* position on that has to be decided and 
> communicated ( if not voted on ).
>
>

Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0

[David Handermann <ex...@apache.org>]

Hi Otto,

Thanks for the reply, that is a good question.

There is certainly a need to maintain the current version 1 branch for some
amount of time, but the exact amount of time will need to be determined.

Point 10 of the Proposed Release Goals includes implementing migration
tools, which will have to be implemented in subsequent version 1 releases,
so support for version 1 would not go away any time soon. It will become
more difficult to maintain libraries as time goes on, but we should also
identify some strategies for subsequent maintenance releases.

I anticipate the need for future votes to sunset version 1, but that should
not occur until there has been significant work on version 2 and associated
migration tools, with documentation.

The main purpose of the 2.0 Proposed Release Goals is to focus that scope,
and as you noted, we should give some parallel consideration to scoping for
version 1 releases.

Regards,
David Handermann

On Sat, Dec 10, 2022 at 8:42 PM Otto Fowler <ot...@gmail.com> wrote:

> Sorry to be late to this, the goals seem great. The question that comes to
> my mind is will the current 1.x line will be maintained?
>
> That may be a parallel issue to the goals, but it is important if we are
> dropping support for Java versions.
>
> I would think that *some* position on that has to be decided and
> communicated ( if not voted on ).
>
>
>
>
> From: David Handermann <ex...@apache.org>
> <ex...@apache.org>
> Reply: dev@nifi.apache.org <de...@nifi.apache.org> <de...@nifi.apache.org>
> Date: December 10, 2022 at 10:46:51
> To: dev@nifi.apache.org <de...@nifi.apache.org> <de...@nifi.apache.org>
> Subject:  Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0
>
> Thanks for the additional feedback Ryan and Kevin!
>
> There appears to be general agreement on the path forward, so I will
> initiate a vote thread soon. I'm sure there are additional details to be
> worked out, and we can address those following a vote on the general
> goals.
>
> Regards,
> David Handermannn
>
> On Wed, Dec 7, 2022 at 5:41 PM Kevin Doran <kd...@apache.org> wrote:
>
> > Thanks, David. The updated wiki page looks good and I’m very supportive
> of
> > the proposal
> >
> > I support a narrower scope for 2.x and an eventual 3.x line sooner
> rather
> > than later. It takes some pressure off trying to fit everything into
> this
> > 2.x change / migration
> >
> > Kevin
> >
> > On Dec 7, 2022 at 18:07:35, Ryan Hendrickson <
> > ryan.andrew.hendrickson@gmail.com> wrote:
> >
> > > The Proposed Release Goals and Deprecated Components and Features
> pages
> > > look great.
> > >
> > > I appreciate the minor leap of Java 11 as a 2.x requirement vs Java
> 17.
> > >
> > > Maybe once there is a timeline, the 2.x branch could be scheduled only
> to
> > > be alive for a minor amount of time... a year, etc. Then a later 2.x
> or
> > 3.0
> > > release would bring about Java 17.
> > >
> > > Ryan
> > >
> > > On Wed, Dec 7, 2022 at 3:09 PM Mike Thomsen <mi...@gmail.com>
> > > wrote:
> > >
> > > > Mike - what do you mean by "controller service-based configuration
> for
> > >
> > >
> > > Using controller services for configuring bundles that connect an
> > >
> > > external service such as Cassandra, Elasticsearch, etc. and removing
> > >
> > > the option to configure connections on the processor.
> > >
> > >
> > > > I don't think you were suggesting the minimum version be Java 17,
> were
> > >
> > > you?
> > >
> > >
> > > I was. Partly as devil's advocate, partly because I actually want to
> > >
> > > use Java 17 as a daily driver.
> > >
> > >
> > > On Wed, Dec 7, 2022 at 2:20 PM Mark Bean <ma...@gmail.com>
> wrote:
> > >
> > > >
> > >
> > > > I agree this is a great start to a discussion with pointers to
> > important
> > >
> > > > docs for the 2.0 transition. Thanks David!
> > >
> > > >
> > >
> > > > Mike - what do you mean by "controller service-based configuration
> for
> > >
> > > > connection details"?
> > >
> > > >
> > >
> > > > Also, the transition from Java 11 to 17 is not without potential
> > issues.
> > >
> > > > I've discovered one already. [1] I support stepping up on Java
> version
> > >
> > > > requirements. Perhaps rather than the currently stated "Requires
> Java 8
> > >
> > > or
> > >
> > > > Java 11", the requirement can be "Requires Java 11 or Java 17". I
> don't
> > >
> > > > think you were suggesting the minimum version be Java 17, were you?
> > >
> > > Either
> > >
> > > > way, the issue with Java 17 needs to be identified and fixed as well
> as
> > >
> > > > more thorough testing to find other possible edge cases before we
> move
> > >
> > > > forward too aggressively.
> > >
> > > >
> > >
> > > > [1] https://issues.apache.org/jira/browse/NIFI-10958
> > >
> > > >
> > >
> > > > On Wed, Dec 7, 2022 at 1:33 PM Mike Thomsen <mi...@gmail.com>
>
> > >
> > > wrote:
> > >
> > > >
> > >
> > > > > Really good start on the discussion. One thing I'm curious about
> is
> > >
> > > > > Java 11 vs 17. Java 8 -> 11 is major jump that I can understand
> why
> > >
> > > > > businesses scoffed at that for a long time, but the lift from 11
> to
> > 17
> > >
> > > > > was about like 7 -> 8. A 2.0 release seems like a good time to
> jump
> > >
> > > > > straight to the latest official LTS for Java and start
> greenlighting
> > >
> > > > > new language features that might simplify things.
> > >
> > > > >
> > >
> > > > > I would also add (since I didn't see it) a design goal of forcing
> a
> > >
> > > > > complete shift in all bundles to using controller service-based
> > >
> > > > > configurations for connection details. 2.0 feels like a really
> good
> > >
> > > > > time for us to establish a community-wide best practice of
> > >
> > > > > centralizing configurations in dedicated components.
> > >
> > > > >
> > >
> > > > > On Wed, Dec 7, 2022 at 9:13 AM Mark Payne <ma...@hotmail.com>
> > >
> > > wrote:
> > >
> > > > > >
> > >
> > > > > > Yeah, agreed. I am very supportive, as well.
> > >
> > > > > >
> > >
> > > > > > Thanks for taking the time to put this together, David.
> > >
> > > > > >
> > >
> > > > > > -Mark
> > >
> > > > > >
> > >
> > > > > >
> > >
> > > > > > > On Dec 7, 2022, at 4:07 AM, Pierre Villard <
> > >
> > > > > pierre.villard.fr@gmail.com> wrote:
> > >
> > > > > > >
> > >
> > > > > > > Thanks for putting this together David. This is an excellent
> > >
> > > writeup
> > >
> > > > > and
> > >
> > > > > > > it's great to have a release where we focus on tech debt as
> well
> > as
> > >
> > > > > making
> > >
> > > > > > > sure we stay up to date with our dependencies and what we
> > support.
> > >
> > > > > This is
> > >
> > > > > > > a great opportunity for us to clean a lot of things in our
> code
> > >
> > > and I
> > >
> > > > > can't
> > >
> > > > > > > wait for us to get started with this. I'm definitely a +1 to
> > have a
> > >
> > > > > formal
> > >
> > > > > > > vote on this proposal.
> > >
> > > > > > >
> > >
> > > > > > > Thanks,
> > >
> > > > > > > Pierre
> > >
> > > > > > >
> > >
> > > > > > > Le mar. 6 déc. 2022 à 23:50, Joe Witt <jo...@gmail.com> a
> > >
> > > écrit :
> > >
> > > > > > >
> > >
> > > > > > >> David, All,
> > >
> > > > > > >>
> > >
> > > > > > >> This is an excellent writeup/good framing. I am supportive of
> > >
> > > this
> > >
> > > > > > >> as-is since it is achievable and lays out a clear path. We
> can
> > >
> > > make
> > >
> > > > > > >> milestone releases of NiFi 2.0.0 along the way until we
> achieve
> > >
> > > all
> > >
> > > > > > >> the stated goals. I assume migration bits will be the long
> pole
> > >
> > > and
> > >
> > > > > > >> once we have them sorted we can kick out a 2.0.0. We already
> > >
> > > have a
> > >
> > > > > > >> version guide that governs how long we'd keep 1.x maintained
> > >
> > > though
> > >
> > > > > > >> the phase out is pretty natural as we move main to a 2.0.0
> basis
> > >
> > > > > > >> anyway.
> > >
> > > > > > >>
> > >
> > > > > > >> Not to confuse this thread but it makes me think we could do
> a
> > >
> > > similar
> > >
> > > > > > >> framing for a NiFi 3.0 which lays out a potentially new
> approach
> > >
> > > to
> > >
> > > > > > >> NiFi decoupling the web/interface from the runtime/operations
> > and
> > >
> > > one
> > >
> > > > > > >> which is more fundamentally K8S based. But we can cross that
> > >
> > > bridge a
> > >
> > > > > > >> bit later. Does seem more and more like folks in the
> community
> > >
> > > would
> > >
> > > > > > >> like to know more about the potential directions we can go.
> > >
> > > > > > >>
> > >
> > > > > > >> Thanks!
> > >
> > > > > > >> Joe
> > >
> > > > > > >>
> > >
> > > > > > >> On Tue, Dec 6, 2022 at 1:53 PM David Handermann
> > >
> > > > > > >> <ex...@apache.org> wrote:
> > >
> > > > > > >>>
> > >
> > > > > > >>> Team,
> > >
> > > > > > >>>
> > >
> > > > > > >>> With the release of NiFi 1.19.0 deprecating support for Java
> 8,
> > >
> > > the
> > >
> > > > > end
> > >
> > > > > > >> of
> > >
> > > > > > >>> the year provides a good opportunity for finalizing general
> > >
> > > release
> > >
> > > > > goals
> > >
> > > > > > >>> for NiFi 2.0.
> > >
> > > > > > >>>
> > >
> > > > > > >>> Based on previous discussions from July 2021 [1] and June
> 2022
> > >
> > > [2],
> > >
> > > > > there
> > >
> > > > > > >>> seems to be general agreement with focusing a NiFi 2.0
> release
> > on
> > >
> > > > > > >> reducing
> > >
> > > > > > >>> technical debt while providing a straightforward upgrade
> path
> > for
> > >
> > > > > current
> > >
> > > > > > >>> deployments.
> > >
> > > > > > >>>
> > >
> > > > > > >>> I have updated the NiFi 2.0 Proposed Release Goals [3] to
> > reflect
> > >
> > > > > more
> > >
> > > > > > >>> recent progress in several areas. I also linked the
> Deprecated
> > >
> > > > > Components
> > >
> > > > > > >>> and Features [4] page outlining the current state of
> deprecated
> > >
> > > > > > >>> capabilities.
> > >
> > > > > > >>>
> > >
> > > > > > >>> The most recent update to the Proposed Release Goals
> outlines
> > >
> > > > > > >> implementing
> > >
> > > > > > >>> migration tooling to make the upgrade process as easy as
> > >
> > > possible.
> > >
> > > > > The
> > >
> > > > > > >>> addition of dedicated deprecation logging in NiFi 1.18.0
> makes
> > it
> > >
> > > > > easier
> > >
> > > > > > >> to
> > >
> > > > > > >>> warn of breaking changes, but the goal of migration tooling
> is
> > to
> > >
> > > > > make it
> > >
> > > > > > >>> easier to upgrade configurations.
> > >
> > > > > > >>>
> > >
> > > > > > >>> The Proposed Release Goals does not include any release
> > timelines
> > >
> > > > > right
> > >
> > > > > > >>> now, and we should anticipate supporting version 1 for a
> > >
> > > reasonable
> > >
> > > > > > >> period
> > >
> > > > > > >>> of time. As more and more libraries deprecate and drop
> support
> > >
> > > for
> > >
> > > > > Java
> > >
> > > > > > >> 8,
> > >
> > > > > > >>> it will become increasingly difficult to maintain a support
> > >
> > > branch,
> > >
> > > > > which
> > >
> > > > > > >>> is one of the main drivers behind a NiFi 2.0 release that
> drops
> > >
> > > > > support
> > >
> > > > > > >> for
> > >
> > > > > > >>> Java 8.
> > >
> > > > > > >>>
> > >
> > > > > > >>> The general development strategy should involve
> transitioning
> > the
> > >
> > > > > main
> > >
> > > > > > >>> branch to a 2.0.0-SNAPSHOT version so new features and fixes
> > >
> > > will be
> > >
> > > > > > >>> targeted to the new version. Migration tooling will need to
> be
> > >
> > > > > > >> implemented
> > >
> > > > > > >>> on a version 1 support branch, and fixes can be backported
> > where
> > >
> > > > > > >> possible,
> > >
> > > > > > >>> in preparation for subsequent version 1 releases.
> > >
> > > > > > >>>
> > >
> > > > > > >>> With that background, I would like to move to a formal vote
> > soon,
> > >
> > > > > > >> changing
> > >
> > > > > > >>> the Proposed Release Goals document to Planned Release
> Goals.
> > >
> > > Please
> > >
> > > > > > >> weigh
> > >
> > > > > > >>> the general goals highlighted, and if there are no major
> > >
> > > roadblocks
> > >
> > > > > > >>> identified, I will follow up soon with a vote thread.
> > >
> > > > > > >>>
> > >
> > > > > > >>> Regards,
> > >
> > > > > > >>> David Handermann
> > >
> > > > > > >>>
> > >
> > > > > > >>> [1]
> > >
> > > https://lists.apache.org/thread/yj8scrdbx3pdo7990123mc03q24rn1m7
> > >
> > > > > > >>> [2]
> > >
> > > https://lists.apache.org/thread/mm1xf3b9nvrcgytb92oy3swvvc45fl34
> > >
> > > > > > >>> [3]
> > >
> > > > > > >>>
> > >
> > > > > > >>
> > >
> > > > >
> > >
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/NIFI/NiFi+2.0+Proposed+Release+Goals
> > >
> > > > > > >>> [4]
> > >
> > > > > > >>>
> > >
> > > > > > >>
> > >
> > > > >
> > >
> > >
> > >
> >
> https://cwiki.apache.org/confluence/display/NIFI/Deprecated+Components+and+Features
> > >
> > > > > > >>
> > >
> > > > > >
> > >
> > > > >
> > >
> > >
> > >
> >
>
>

Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0

[Otto Fowler <ot...@gmail.com>]

Sorry to be late to this, the goals seem great. The question that comes to
my mind is will the current 1.x line will be maintained?

That may be a parallel issue to the goals, but it is important if we are
dropping support for Java versions.

I would think that *some* position on that has to be decided and
communicated ( if not voted on ).




From: David Handermann <ex...@apache.org>
<ex...@apache.org>
Reply: dev@nifi.apache.org <de...@nifi.apache.org> <de...@nifi.apache.org>
Date: December 10, 2022 at 10:46:51
To: dev@nifi.apache.org <de...@nifi.apache.org> <de...@nifi.apache.org>
Subject:  Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0

Thanks for the additional feedback Ryan and Kevin!

There appears to be general agreement on the path forward, so I will
initiate a vote thread soon. I'm sure there are additional details to be
worked out, and we can address those following a vote on the general goals.

Regards,
David Handermannn

On Wed, Dec 7, 2022 at 5:41 PM Kevin Doran <kd...@apache.org> wrote:

> Thanks, David. The updated wiki page looks good and I’m very supportive
of
> the proposal
>
> I support a narrower scope for 2.x and an eventual 3.x line sooner rather
> than later. It takes some pressure off trying to fit everything into this
> 2.x change / migration
>
> Kevin
>
> On Dec 7, 2022 at 18:07:35, Ryan Hendrickson <
> ryan.andrew.hendrickson@gmail.com> wrote:
>
> > The Proposed Release Goals and Deprecated Components and Features pages
> > look great.
> >
> > I appreciate the minor leap of Java 11 as a 2.x requirement vs Java 17.
> >
> > Maybe once there is a timeline, the 2.x branch could be scheduled only
to
> > be alive for a minor amount of time... a year, etc. Then a later 2.x or
> 3.0
> > release would bring about Java 17.
> >
> > Ryan
> >
> > On Wed, Dec 7, 2022 at 3:09 PM Mike Thomsen <mi...@gmail.com>
> > wrote:
> >
> > > Mike - what do you mean by "controller service-based configuration
for
> >
> >
> > Using controller services for configuring bundles that connect an
> >
> > external service such as Cassandra, Elasticsearch, etc. and removing
> >
> > the option to configure connections on the processor.
> >
> >
> > > I don't think you were suggesting the minimum version be Java 17,
were
> >
> > you?
> >
> >
> > I was. Partly as devil's advocate, partly because I actually want to
> >
> > use Java 17 as a daily driver.
> >
> >
> > On Wed, Dec 7, 2022 at 2:20 PM Mark Bean <ma...@gmail.com> wrote:
> >
> > >
> >
> > > I agree this is a great start to a discussion with pointers to
> important
> >
> > > docs for the 2.0 transition. Thanks David!
> >
> > >
> >
> > > Mike - what do you mean by "controller service-based configuration
for
> >
> > > connection details"?
> >
> > >
> >
> > > Also, the transition from Java 11 to 17 is not without potential
> issues.
> >
> > > I've discovered one already. [1] I support stepping up on Java
version
> >
> > > requirements. Perhaps rather than the currently stated "Requires Java
8
> >
> > or
> >
> > > Java 11", the requirement can be "Requires Java 11 or Java 17". I
don't
> >
> > > think you were suggesting the minimum version be Java 17, were you?
> >
> > Either
> >
> > > way, the issue with Java 17 needs to be identified and fixed as well
as
> >
> > > more thorough testing to find other possible edge cases before we
move
> >
> > > forward too aggressively.
> >
> > >
> >
> > > [1] https://issues.apache.org/jira/browse/NIFI-10958
> >
> > >
> >
> > > On Wed, Dec 7, 2022 at 1:33 PM Mike Thomsen <mi...@gmail.com>
> >
> > wrote:
> >
> > >
> >
> > > > Really good start on the discussion. One thing I'm curious about is
> >
> > > > Java 11 vs 17. Java 8 -> 11 is major jump that I can understand why
> >
> > > > businesses scoffed at that for a long time, but the lift from 11 to
> 17
> >
> > > > was about like 7 -> 8. A 2.0 release seems like a good time to jump
> >
> > > > straight to the latest official LTS for Java and start
greenlighting
> >
> > > > new language features that might simplify things.
> >
> > > >
> >
> > > > I would also add (since I didn't see it) a design goal of forcing a
> >
> > > > complete shift in all bundles to using controller service-based
> >
> > > > configurations for connection details. 2.0 feels like a really good
> >
> > > > time for us to establish a community-wide best practice of
> >
> > > > centralizing configurations in dedicated components.
> >
> > > >
> >
> > > > On Wed, Dec 7, 2022 at 9:13 AM Mark Payne <ma...@hotmail.com>
> >
> > wrote:
> >
> > > > >
> >
> > > > > Yeah, agreed. I am very supportive, as well.
> >
> > > > >
> >
> > > > > Thanks for taking the time to put this together, David.
> >
> > > > >
> >
> > > > > -Mark
> >
> > > > >
> >
> > > > >
> >
> > > > > > On Dec 7, 2022, at 4:07 AM, Pierre Villard <
> >
> > > > pierre.villard.fr@gmail.com> wrote:
> >
> > > > > >
> >
> > > > > > Thanks for putting this together David. This is an excellent
> >
> > writeup
> >
> > > > and
> >
> > > > > > it's great to have a release where we focus on tech debt as
well
> as
> >
> > > > making
> >
> > > > > > sure we stay up to date with our dependencies and what we
> support.
> >
> > > > This is
> >
> > > > > > a great opportunity for us to clean a lot of things in our code
> >
> > and I
> >
> > > > can't
> >
> > > > > > wait for us to get started with this. I'm definitely a +1 to
> have a
> >
> > > > formal
> >
> > > > > > vote on this proposal.
> >
> > > > > >
> >
> > > > > > Thanks,
> >
> > > > > > Pierre
> >
> > > > > >
> >
> > > > > > Le mar. 6 déc. 2022 à 23:50, Joe Witt <jo...@gmail.com> a
> >
> > écrit :
> >
> > > > > >
> >
> > > > > >> David, All,
> >
> > > > > >>
> >
> > > > > >> This is an excellent writeup/good framing. I am supportive of
> >
> > this
> >
> > > > > >> as-is since it is achievable and lays out a clear path. We can
> >
> > make
> >
> > > > > >> milestone releases of NiFi 2.0.0 along the way until we
achieve
> >
> > all
> >
> > > > > >> the stated goals. I assume migration bits will be the long
pole
> >
> > and
> >
> > > > > >> once we have them sorted we can kick out a 2.0.0. We already
> >
> > have a
> >
> > > > > >> version guide that governs how long we'd keep 1.x maintained
> >
> > though
> >
> > > > > >> the phase out is pretty natural as we move main to a 2.0.0
basis
> >
> > > > > >> anyway.
> >
> > > > > >>
> >
> > > > > >> Not to confuse this thread but it makes me think we could do a
> >
> > similar
> >
> > > > > >> framing for a NiFi 3.0 which lays out a potentially new
approach
> >
> > to
> >
> > > > > >> NiFi decoupling the web/interface from the runtime/operations
> and
> >
> > one
> >
> > > > > >> which is more fundamentally K8S based. But we can cross that
> >
> > bridge a
> >
> > > > > >> bit later. Does seem more and more like folks in the community
> >
> > would
> >
> > > > > >> like to know more about the potential directions we can go.
> >
> > > > > >>
> >
> > > > > >> Thanks!
> >
> > > > > >> Joe
> >
> > > > > >>
> >
> > > > > >> On Tue, Dec 6, 2022 at 1:53 PM David Handermann
> >
> > > > > >> <ex...@apache.org> wrote:
> >
> > > > > >>>
> >
> > > > > >>> Team,
> >
> > > > > >>>
> >
> > > > > >>> With the release of NiFi 1.19.0 deprecating support for Java
8,
> >
> > the
> >
> > > > end
> >
> > > > > >> of
> >
> > > > > >>> the year provides a good opportunity for finalizing general
> >
> > release
> >
> > > > goals
> >
> > > > > >>> for NiFi 2.0.
> >
> > > > > >>>
> >
> > > > > >>> Based on previous discussions from July 2021 [1] and June
2022
> >
> > [2],
> >
> > > > there
> >
> > > > > >>> seems to be general agreement with focusing a NiFi 2.0
release
> on
> >
> > > > > >> reducing
> >
> > > > > >>> technical debt while providing a straightforward upgrade path
> for
> >
> > > > current
> >
> > > > > >>> deployments.
> >
> > > > > >>>
> >
> > > > > >>> I have updated the NiFi 2.0 Proposed Release Goals [3] to
> reflect
> >
> > > > more
> >
> > > > > >>> recent progress in several areas. I also linked the
Deprecated
> >
> > > > Components
> >
> > > > > >>> and Features [4] page outlining the current state of
deprecated
> >
> > > > > >>> capabilities.
> >
> > > > > >>>
> >
> > > > > >>> The most recent update to the Proposed Release Goals outlines
> >
> > > > > >> implementing
> >
> > > > > >>> migration tooling to make the upgrade process as easy as
> >
> > possible.
> >
> > > > The
> >
> > > > > >>> addition of dedicated deprecation logging in NiFi 1.18.0
makes
> it
> >
> > > > easier
> >
> > > > > >> to
> >
> > > > > >>> warn of breaking changes, but the goal of migration tooling
is
> to
> >
> > > > make it
> >
> > > > > >>> easier to upgrade configurations.
> >
> > > > > >>>
> >
> > > > > >>> The Proposed Release Goals does not include any release
> timelines
> >
> > > > right
> >
> > > > > >>> now, and we should anticipate supporting version 1 for a
> >
> > reasonable
> >
> > > > > >> period
> >
> > > > > >>> of time. As more and more libraries deprecate and drop
support
> >
> > for
> >
> > > > Java
> >
> > > > > >> 8,
> >
> > > > > >>> it will become increasingly difficult to maintain a support
> >
> > branch,
> >
> > > > which
> >
> > > > > >>> is one of the main drivers behind a NiFi 2.0 release that
drops
> >
> > > > support
> >
> > > > > >> for
> >
> > > > > >>> Java 8.
> >
> > > > > >>>
> >
> > > > > >>> The general development strategy should involve transitioning
> the
> >
> > > > main
> >
> > > > > >>> branch to a 2.0.0-SNAPSHOT version so new features and fixes
> >
> > will be
> >
> > > > > >>> targeted to the new version. Migration tooling will need to
be
> >
> > > > > >> implemented
> >
> > > > > >>> on a version 1 support branch, and fixes can be backported
> where
> >
> > > > > >> possible,
> >
> > > > > >>> in preparation for subsequent version 1 releases.
> >
> > > > > >>>
> >
> > > > > >>> With that background, I would like to move to a formal vote
> soon,
> >
> > > > > >> changing
> >
> > > > > >>> the Proposed Release Goals document to Planned Release Goals.
> >
> > Please
> >
> > > > > >> weigh
> >
> > > > > >>> the general goals highlighted, and if there are no major
> >
> > roadblocks
> >
> > > > > >>> identified, I will follow up soon with a vote thread.
> >
> > > > > >>>
> >
> > > > > >>> Regards,
> >
> > > > > >>> David Handermann
> >
> > > > > >>>
> >
> > > > > >>> [1]
> >
> > https://lists.apache.org/thread/yj8scrdbx3pdo7990123mc03q24rn1m7
> >
> > > > > >>> [2]
> >
> > https://lists.apache.org/thread/mm1xf3b9nvrcgytb92oy3swvvc45fl34
> >
> > > > > >>> [3]
> >
> > > > > >>>
> >
> > > > > >>
> >
> > > >
> >
> >
> >
>
https://cwiki.apache.org/confluence/display/NIFI/NiFi+2.0+Proposed+Release+Goals
> >
> > > > > >>> [4]
> >
> > > > > >>>
> >
> > > > > >>
> >
> > > >
> >
> >
> >
>
https://cwiki.apache.org/confluence/display/NIFI/Deprecated+Components+and+Features
> >
> > > > > >>
> >
> > > > >
> >
> > > >
> >
> >
> >
>

Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0

[David Handermann <ex...@apache.org>]

Thanks for the additional feedback Ryan and Kevin!

There appears to be general agreement on the path forward, so I will
initiate a vote thread soon. I'm sure there are additional details to be
worked out, and we can address those following a vote on the general goals.

Regards,
David Handermannn

On Wed, Dec 7, 2022 at 5:41 PM Kevin Doran <kd...@apache.org> wrote:

> Thanks, David. The updated wiki page looks good and I’m very supportive of
> the proposal
>
> I support a narrower scope for 2.x and an eventual 3.x line sooner rather
> than later. It takes some pressure off trying to fit everything into this
> 2.x change / migration
>
> Kevin
>
> On Dec 7, 2022 at 18:07:35, Ryan Hendrickson <
> ryan.andrew.hendrickson@gmail.com> wrote:
>
> > The Proposed Release Goals and Deprecated Components and Features pages
> > look great.
> >
> > I appreciate the minor leap of Java 11 as a 2.x requirement vs Java 17.
> >
> > Maybe once there is a timeline, the 2.x branch could be scheduled only to
> > be alive for a minor amount of time... a year, etc. Then a later 2.x or
> 3.0
> > release would bring about Java 17.
> >
> > Ryan
> >
> > On Wed, Dec 7, 2022 at 3:09 PM Mike Thomsen <mi...@gmail.com>
> > wrote:
> >
> > > Mike - what do you mean by "controller service-based configuration for
> >
> >
> > Using controller services for configuring bundles that connect an
> >
> > external service such as Cassandra, Elasticsearch, etc. and removing
> >
> > the option to configure connections on the processor.
> >
> >
> > > I don't think you were suggesting the minimum version be Java 17, were
> >
> > you?
> >
> >
> > I was. Partly as devil's advocate, partly because I actually want to
> >
> > use Java 17 as a daily driver.
> >
> >
> > On Wed, Dec 7, 2022 at 2:20 PM Mark Bean <ma...@gmail.com> wrote:
> >
> > >
> >
> > > I agree this is a great start to a discussion with pointers to
> important
> >
> > > docs for the 2.0 transition. Thanks David!
> >
> > >
> >
> > > Mike - what do you mean by "controller service-based configuration for
> >
> > > connection details"?
> >
> > >
> >
> > > Also, the transition from Java 11 to 17 is not without potential
> issues.
> >
> > > I've discovered one already. [1] I support stepping up on Java version
> >
> > > requirements. Perhaps rather than the currently stated "Requires Java 8
> >
> > or
> >
> > > Java 11", the requirement can be "Requires Java 11 or Java 17". I don't
> >
> > > think you were suggesting the minimum version be Java 17, were you?
> >
> > Either
> >
> > > way, the issue with Java 17 needs to be identified and fixed as well as
> >
> > > more thorough testing to find other possible edge cases before we move
> >
> > > forward too aggressively.
> >
> > >
> >
> > > [1] https://issues.apache.org/jira/browse/NIFI-10958
> >
> > >
> >
> > > On Wed, Dec 7, 2022 at 1:33 PM Mike Thomsen <mi...@gmail.com>
> >
> > wrote:
> >
> > >
> >
> > > > Really good start on the discussion. One thing I'm curious about is
> >
> > > > Java 11 vs 17. Java 8 -> 11 is major jump that I can understand why
> >
> > > > businesses scoffed at that for a long time, but the lift from 11 to
> 17
> >
> > > > was about like 7 -> 8. A 2.0 release seems like a good time to jump
> >
> > > > straight to the latest official LTS for Java and start greenlighting
> >
> > > > new language features that might simplify things.
> >
> > > >
> >
> > > > I would also add (since I didn't see it) a design goal of forcing a
> >
> > > > complete shift in all bundles to using controller service-based
> >
> > > > configurations for connection details. 2.0 feels like a really good
> >
> > > > time for us to establish a community-wide best practice of
> >
> > > > centralizing configurations in dedicated components.
> >
> > > >
> >
> > > > On Wed, Dec 7, 2022 at 9:13 AM Mark Payne <ma...@hotmail.com>
> >
> > wrote:
> >
> > > > >
> >
> > > > > Yeah, agreed. I am very supportive, as well.
> >
> > > > >
> >
> > > > > Thanks for taking the time to put this together, David.
> >
> > > > >
> >
> > > > > -Mark
> >
> > > > >
> >
> > > > >
> >
> > > > > > On Dec 7, 2022, at 4:07 AM, Pierre Villard <
> >
> > > > pierre.villard.fr@gmail.com> wrote:
> >
> > > > > >
> >
> > > > > > Thanks for putting this together David. This is an excellent
> >
> > writeup
> >
> > > > and
> >
> > > > > > it's great to have a release where we focus on tech debt as well
> as
> >
> > > > making
> >
> > > > > > sure we stay up to date with our dependencies and what we
> support.
> >
> > > > This is
> >
> > > > > > a great opportunity for us to clean a lot of things in our code
> >
> > and I
> >
> > > > can't
> >
> > > > > > wait for us to get started with this. I'm definitely a +1 to
> have a
> >
> > > > formal
> >
> > > > > > vote on this proposal.
> >
> > > > > >
> >
> > > > > > Thanks,
> >
> > > > > > Pierre
> >
> > > > > >
> >
> > > > > > Le mar. 6 déc. 2022 à 23:50, Joe Witt <jo...@gmail.com> a
> >
> > écrit :
> >
> > > > > >
> >
> > > > > >> David, All,
> >
> > > > > >>
> >
> > > > > >> This is an excellent writeup/good framing.  I am supportive of
> >
> > this
> >
> > > > > >> as-is since it is achievable and lays out a clear path.  We can
> >
> > make
> >
> > > > > >> milestone releases of NiFi 2.0.0 along the way until we achieve
> >
> > all
> >
> > > > > >> the stated goals. I assume migration bits will be the long pole
> >
> > and
> >
> > > > > >> once we have them sorted we can kick out a 2.0.0.   We already
> >
> > have a
> >
> > > > > >> version guide that governs how long we'd keep 1.x maintained
> >
> > though
> >
> > > > > >> the phase out is pretty natural as we move main to a 2.0.0 basis
> >
> > > > > >> anyway.
> >
> > > > > >>
> >
> > > > > >> Not to confuse this thread but it makes me think we could do a
> >
> > similar
> >
> > > > > >> framing for a NiFi 3.0 which lays out a potentially new approach
> >
> > to
> >
> > > > > >> NiFi decoupling the web/interface from the runtime/operations
> and
> >
> > one
> >
> > > > > >> which is more fundamentally K8S based.  But we can cross that
> >
> > bridge a
> >
> > > > > >> bit later.  Does seem more and more like folks in the community
> >
> > would
> >
> > > > > >> like to know more about the potential directions we can go.
> >
> > > > > >>
> >
> > > > > >> Thanks!
> >
> > > > > >> Joe
> >
> > > > > >>
> >
> > > > > >> On Tue, Dec 6, 2022 at 1:53 PM David Handermann
> >
> > > > > >> <ex...@apache.org> wrote:
> >
> > > > > >>>
> >
> > > > > >>> Team,
> >
> > > > > >>>
> >
> > > > > >>> With the release of NiFi 1.19.0 deprecating support for Java 8,
> >
> > the
> >
> > > > end
> >
> > > > > >> of
> >
> > > > > >>> the year provides a good opportunity for finalizing general
> >
> > release
> >
> > > > goals
> >
> > > > > >>> for NiFi 2.0.
> >
> > > > > >>>
> >
> > > > > >>> Based on previous discussions from July 2021 [1] and June 2022
> >
> > [2],
> >
> > > > there
> >
> > > > > >>> seems to be general agreement with focusing a NiFi 2.0 release
> on
> >
> > > > > >> reducing
> >
> > > > > >>> technical debt while providing a straightforward upgrade path
> for
> >
> > > > current
> >
> > > > > >>> deployments.
> >
> > > > > >>>
> >
> > > > > >>> I have updated the NiFi 2.0 Proposed Release Goals [3] to
> reflect
> >
> > > > more
> >
> > > > > >>> recent progress in several areas. I also linked the Deprecated
> >
> > > > Components
> >
> > > > > >>> and Features [4] page outlining the current state of deprecated
> >
> > > > > >>> capabilities.
> >
> > > > > >>>
> >
> > > > > >>> The most recent update to the Proposed Release Goals outlines
> >
> > > > > >> implementing
> >
> > > > > >>> migration tooling to make the upgrade process as easy as
> >
> > possible.
> >
> > > > The
> >
> > > > > >>> addition of dedicated deprecation logging in NiFi 1.18.0 makes
> it
> >
> > > > easier
> >
> > > > > >> to
> >
> > > > > >>> warn of breaking changes, but the goal of migration tooling is
> to
> >
> > > > make it
> >
> > > > > >>> easier to upgrade configurations.
> >
> > > > > >>>
> >
> > > > > >>> The Proposed Release Goals does not include any release
> timelines
> >
> > > > right
> >
> > > > > >>> now, and we should anticipate supporting version 1 for a
> >
> > reasonable
> >
> > > > > >> period
> >
> > > > > >>> of time. As more and more libraries deprecate and drop support
> >
> > for
> >
> > > > Java
> >
> > > > > >> 8,
> >
> > > > > >>> it will become increasingly difficult to maintain a support
> >
> > branch,
> >
> > > > which
> >
> > > > > >>> is one of the main drivers behind a NiFi 2.0 release that drops
> >
> > > > support
> >
> > > > > >> for
> >
> > > > > >>> Java 8.
> >
> > > > > >>>
> >
> > > > > >>> The general development strategy should involve transitioning
> the
> >
> > > > main
> >
> > > > > >>> branch to a 2.0.0-SNAPSHOT version so new features and fixes
> >
> > will be
> >
> > > > > >>> targeted to the new version. Migration tooling will need to be
> >
> > > > > >> implemented
> >
> > > > > >>> on a version 1 support branch, and fixes can be backported
> where
> >
> > > > > >> possible,
> >
> > > > > >>> in preparation for subsequent version 1 releases.
> >
> > > > > >>>
> >
> > > > > >>> With that background, I would like to move to a formal vote
> soon,
> >
> > > > > >> changing
> >
> > > > > >>> the Proposed Release Goals document to Planned Release Goals.
> >
> > Please
> >
> > > > > >> weigh
> >
> > > > > >>> the general goals highlighted, and if there are no major
> >
> > roadblocks
> >
> > > > > >>> identified, I will follow up soon with a vote thread.
> >
> > > > > >>>
> >
> > > > > >>> Regards,
> >
> > > > > >>> David Handermann
> >
> > > > > >>>
> >
> > > > > >>> [1]
> >
> > https://lists.apache.org/thread/yj8scrdbx3pdo7990123mc03q24rn1m7
> >
> > > > > >>> [2]
> >
> > https://lists.apache.org/thread/mm1xf3b9nvrcgytb92oy3swvvc45fl34
> >
> > > > > >>> [3]
> >
> > > > > >>>
> >
> > > > > >>
> >
> > > >
> >
> >
> >
> https://cwiki.apache.org/confluence/display/NIFI/NiFi+2.0+Proposed+Release+Goals
> >
> > > > > >>> [4]
> >
> > > > > >>>
> >
> > > > > >>
> >
> > > >
> >
> >
> >
> https://cwiki.apache.org/confluence/display/NIFI/Deprecated+Components+and+Features
> >
> > > > > >>
> >
> > > > >
> >
> > > >
> >
> >
> >
>

Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0

[Kevin Doran <kd...@apache.org>]

Thanks, David. The updated wiki page looks good and I’m very supportive of
the proposal

I support a narrower scope for 2.x and an eventual 3.x line sooner rather
than later. It takes some pressure off trying to fit everything into this
2.x change / migration

Kevin

On Dec 7, 2022 at 18:07:35, Ryan Hendrickson <
ryan.andrew.hendrickson@gmail.com> wrote:

> The Proposed Release Goals and Deprecated Components and Features pages
> look great.
>
> I appreciate the minor leap of Java 11 as a 2.x requirement vs Java 17.
>
> Maybe once there is a timeline, the 2.x branch could be scheduled only to
> be alive for a minor amount of time... a year, etc. Then a later 2.x or 3.0
> release would bring about Java 17.
>
> Ryan
>
> On Wed, Dec 7, 2022 at 3:09 PM Mike Thomsen <mi...@gmail.com>
> wrote:
>
> > Mike - what do you mean by "controller service-based configuration for
>
>
> Using controller services for configuring bundles that connect an
>
> external service such as Cassandra, Elasticsearch, etc. and removing
>
> the option to configure connections on the processor.
>
>
> > I don't think you were suggesting the minimum version be Java 17, were
>
> you?
>
>
> I was. Partly as devil's advocate, partly because I actually want to
>
> use Java 17 as a daily driver.
>
>
> On Wed, Dec 7, 2022 at 2:20 PM Mark Bean <ma...@gmail.com> wrote:
>
> >
>
> > I agree this is a great start to a discussion with pointers to important
>
> > docs for the 2.0 transition. Thanks David!
>
> >
>
> > Mike - what do you mean by "controller service-based configuration for
>
> > connection details"?
>
> >
>
> > Also, the transition from Java 11 to 17 is not without potential issues.
>
> > I've discovered one already. [1] I support stepping up on Java version
>
> > requirements. Perhaps rather than the currently stated "Requires Java 8
>
> or
>
> > Java 11", the requirement can be "Requires Java 11 or Java 17". I don't
>
> > think you were suggesting the minimum version be Java 17, were you?
>
> Either
>
> > way, the issue with Java 17 needs to be identified and fixed as well as
>
> > more thorough testing to find other possible edge cases before we move
>
> > forward too aggressively.
>
> >
>
> > [1] https://issues.apache.org/jira/browse/NIFI-10958
>
> >
>
> > On Wed, Dec 7, 2022 at 1:33 PM Mike Thomsen <mi...@gmail.com>
>
> wrote:
>
> >
>
> > > Really good start on the discussion. One thing I'm curious about is
>
> > > Java 11 vs 17. Java 8 -> 11 is major jump that I can understand why
>
> > > businesses scoffed at that for a long time, but the lift from 11 to 17
>
> > > was about like 7 -> 8. A 2.0 release seems like a good time to jump
>
> > > straight to the latest official LTS for Java and start greenlighting
>
> > > new language features that might simplify things.
>
> > >
>
> > > I would also add (since I didn't see it) a design goal of forcing a
>
> > > complete shift in all bundles to using controller service-based
>
> > > configurations for connection details. 2.0 feels like a really good
>
> > > time for us to establish a community-wide best practice of
>
> > > centralizing configurations in dedicated components.
>
> > >
>
> > > On Wed, Dec 7, 2022 at 9:13 AM Mark Payne <ma...@hotmail.com>
>
> wrote:
>
> > > >
>
> > > > Yeah, agreed. I am very supportive, as well.
>
> > > >
>
> > > > Thanks for taking the time to put this together, David.
>
> > > >
>
> > > > -Mark
>
> > > >
>
> > > >
>
> > > > > On Dec 7, 2022, at 4:07 AM, Pierre Villard <
>
> > > pierre.villard.fr@gmail.com> wrote:
>
> > > > >
>
> > > > > Thanks for putting this together David. This is an excellent
>
> writeup
>
> > > and
>
> > > > > it's great to have a release where we focus on tech debt as well as
>
> > > making
>
> > > > > sure we stay up to date with our dependencies and what we support.
>
> > > This is
>
> > > > > a great opportunity for us to clean a lot of things in our code
>
> and I
>
> > > can't
>
> > > > > wait for us to get started with this. I'm definitely a +1 to have a
>
> > > formal
>
> > > > > vote on this proposal.
>
> > > > >
>
> > > > > Thanks,
>
> > > > > Pierre
>
> > > > >
>
> > > > > Le mar. 6 déc. 2022 à 23:50, Joe Witt <jo...@gmail.com> a
>
> écrit :
>
> > > > >
>
> > > > >> David, All,
>
> > > > >>
>
> > > > >> This is an excellent writeup/good framing.  I am supportive of
>
> this
>
> > > > >> as-is since it is achievable and lays out a clear path.  We can
>
> make
>
> > > > >> milestone releases of NiFi 2.0.0 along the way until we achieve
>
> all
>
> > > > >> the stated goals. I assume migration bits will be the long pole
>
> and
>
> > > > >> once we have them sorted we can kick out a 2.0.0.   We already
>
> have a
>
> > > > >> version guide that governs how long we'd keep 1.x maintained
>
> though
>
> > > > >> the phase out is pretty natural as we move main to a 2.0.0 basis
>
> > > > >> anyway.
>
> > > > >>
>
> > > > >> Not to confuse this thread but it makes me think we could do a
>
> similar
>
> > > > >> framing for a NiFi 3.0 which lays out a potentially new approach
>
> to
>
> > > > >> NiFi decoupling the web/interface from the runtime/operations and
>
> one
>
> > > > >> which is more fundamentally K8S based.  But we can cross that
>
> bridge a
>
> > > > >> bit later.  Does seem more and more like folks in the community
>
> would
>
> > > > >> like to know more about the potential directions we can go.
>
> > > > >>
>
> > > > >> Thanks!
>
> > > > >> Joe
>
> > > > >>
>
> > > > >> On Tue, Dec 6, 2022 at 1:53 PM David Handermann
>
> > > > >> <ex...@apache.org> wrote:
>
> > > > >>>
>
> > > > >>> Team,
>
> > > > >>>
>
> > > > >>> With the release of NiFi 1.19.0 deprecating support for Java 8,
>
> the
>
> > > end
>
> > > > >> of
>
> > > > >>> the year provides a good opportunity for finalizing general
>
> release
>
> > > goals
>
> > > > >>> for NiFi 2.0.
>
> > > > >>>
>
> > > > >>> Based on previous discussions from July 2021 [1] and June 2022
>
> [2],
>
> > > there
>
> > > > >>> seems to be general agreement with focusing a NiFi 2.0 release on
>
> > > > >> reducing
>
> > > > >>> technical debt while providing a straightforward upgrade path for
>
> > > current
>
> > > > >>> deployments.
>
> > > > >>>
>
> > > > >>> I have updated the NiFi 2.0 Proposed Release Goals [3] to reflect
>
> > > more
>
> > > > >>> recent progress in several areas. I also linked the Deprecated
>
> > > Components
>
> > > > >>> and Features [4] page outlining the current state of deprecated
>
> > > > >>> capabilities.
>
> > > > >>>
>
> > > > >>> The most recent update to the Proposed Release Goals outlines
>
> > > > >> implementing
>
> > > > >>> migration tooling to make the upgrade process as easy as
>
> possible.
>
> > > The
>
> > > > >>> addition of dedicated deprecation logging in NiFi 1.18.0 makes it
>
> > > easier
>
> > > > >> to
>
> > > > >>> warn of breaking changes, but the goal of migration tooling is to
>
> > > make it
>
> > > > >>> easier to upgrade configurations.
>
> > > > >>>
>
> > > > >>> The Proposed Release Goals does not include any release timelines
>
> > > right
>
> > > > >>> now, and we should anticipate supporting version 1 for a
>
> reasonable
>
> > > > >> period
>
> > > > >>> of time. As more and more libraries deprecate and drop support
>
> for
>
> > > Java
>
> > > > >> 8,
>
> > > > >>> it will become increasingly difficult to maintain a support
>
> branch,
>
> > > which
>
> > > > >>> is one of the main drivers behind a NiFi 2.0 release that drops
>
> > > support
>
> > > > >> for
>
> > > > >>> Java 8.
>
> > > > >>>
>
> > > > >>> The general development strategy should involve transitioning the
>
> > > main
>
> > > > >>> branch to a 2.0.0-SNAPSHOT version so new features and fixes
>
> will be
>
> > > > >>> targeted to the new version. Migration tooling will need to be
>
> > > > >> implemented
>
> > > > >>> on a version 1 support branch, and fixes can be backported where
>
> > > > >> possible,
>
> > > > >>> in preparation for subsequent version 1 releases.
>
> > > > >>>
>
> > > > >>> With that background, I would like to move to a formal vote soon,
>
> > > > >> changing
>
> > > > >>> the Proposed Release Goals document to Planned Release Goals.
>
> Please
>
> > > > >> weigh
>
> > > > >>> the general goals highlighted, and if there are no major
>
> roadblocks
>
> > > > >>> identified, I will follow up soon with a vote thread.
>
> > > > >>>
>
> > > > >>> Regards,
>
> > > > >>> David Handermann
>
> > > > >>>
>
> > > > >>> [1]
>
> https://lists.apache.org/thread/yj8scrdbx3pdo7990123mc03q24rn1m7
>
> > > > >>> [2]
>
> https://lists.apache.org/thread/mm1xf3b9nvrcgytb92oy3swvvc45fl34
>
> > > > >>> [3]
>
> > > > >>>
>
> > > > >>
>
> > >
>
>
> https://cwiki.apache.org/confluence/display/NIFI/NiFi+2.0+Proposed+Release+Goals
>
> > > > >>> [4]
>
> > > > >>>
>
> > > > >>
>
> > >
>
>
> https://cwiki.apache.org/confluence/display/NIFI/Deprecated+Components+and+Features
>
> > > > >>
>
> > > >
>
> > >
>
>
>

Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0

[Ryan Hendrickson <ry...@gmail.com>]

The Proposed Release Goals and Deprecated Components and Features pages
look great.

I appreciate the minor leap of Java 11 as a 2.x requirement vs Java 17.

Maybe once there is a timeline, the 2.x branch could be scheduled only to
be alive for a minor amount of time... a year, etc. Then a later 2.x or 3.0
release would bring about Java 17.

Ryan

On Wed, Dec 7, 2022 at 3:09 PM Mike Thomsen <mi...@gmail.com> wrote:

> > Mike - what do you mean by "controller service-based configuration for
>
> Using controller services for configuring bundles that connect an
> external service such as Cassandra, Elasticsearch, etc. and removing
> the option to configure connections on the processor.
>
> > I don't think you were suggesting the minimum version be Java 17, were
> you?
>
> I was. Partly as devil's advocate, partly because I actually want to
> use Java 17 as a daily driver.
>
> On Wed, Dec 7, 2022 at 2:20 PM Mark Bean <ma...@gmail.com> wrote:
> >
> > I agree this is a great start to a discussion with pointers to important
> > docs for the 2.0 transition. Thanks David!
> >
> > Mike - what do you mean by "controller service-based configuration for
> > connection details"?
> >
> > Also, the transition from Java 11 to 17 is not without potential issues.
> > I've discovered one already. [1] I support stepping up on Java version
> > requirements. Perhaps rather than the currently stated "Requires Java 8
> or
> > Java 11", the requirement can be "Requires Java 11 or Java 17". I don't
> > think you were suggesting the minimum version be Java 17, were you?
> Either
> > way, the issue with Java 17 needs to be identified and fixed as well as
> > more thorough testing to find other possible edge cases before we move
> > forward too aggressively.
> >
> > [1] https://issues.apache.org/jira/browse/NIFI-10958
> >
> > On Wed, Dec 7, 2022 at 1:33 PM Mike Thomsen <mi...@gmail.com>
> wrote:
> >
> > > Really good start on the discussion. One thing I'm curious about is
> > > Java 11 vs 17. Java 8 -> 11 is major jump that I can understand why
> > > businesses scoffed at that for a long time, but the lift from 11 to 17
> > > was about like 7 -> 8. A 2.0 release seems like a good time to jump
> > > straight to the latest official LTS for Java and start greenlighting
> > > new language features that might simplify things.
> > >
> > > I would also add (since I didn't see it) a design goal of forcing a
> > > complete shift in all bundles to using controller service-based
> > > configurations for connection details. 2.0 feels like a really good
> > > time for us to establish a community-wide best practice of
> > > centralizing configurations in dedicated components.
> > >
> > > On Wed, Dec 7, 2022 at 9:13 AM Mark Payne <ma...@hotmail.com>
> wrote:
> > > >
> > > > Yeah, agreed. I am very supportive, as well.
> > > >
> > > > Thanks for taking the time to put this together, David.
> > > >
> > > > -Mark
> > > >
> > > >
> > > > > On Dec 7, 2022, at 4:07 AM, Pierre Villard <
> > > pierre.villard.fr@gmail.com> wrote:
> > > > >
> > > > > Thanks for putting this together David. This is an excellent
> writeup
> > > and
> > > > > it's great to have a release where we focus on tech debt as well as
> > > making
> > > > > sure we stay up to date with our dependencies and what we support.
> > > This is
> > > > > a great opportunity for us to clean a lot of things in our code
> and I
> > > can't
> > > > > wait for us to get started with this. I'm definitely a +1 to have a
> > > formal
> > > > > vote on this proposal.
> > > > >
> > > > > Thanks,
> > > > > Pierre
> > > > >
> > > > > Le mar. 6 déc. 2022 à 23:50, Joe Witt <jo...@gmail.com> a
> écrit :
> > > > >
> > > > >> David, All,
> > > > >>
> > > > >> This is an excellent writeup/good framing.  I am supportive of
> this
> > > > >> as-is since it is achievable and lays out a clear path.  We can
> make
> > > > >> milestone releases of NiFi 2.0.0 along the way until we achieve
> all
> > > > >> the stated goals. I assume migration bits will be the long pole
> and
> > > > >> once we have them sorted we can kick out a 2.0.0.   We already
> have a
> > > > >> version guide that governs how long we'd keep 1.x maintained
> though
> > > > >> the phase out is pretty natural as we move main to a 2.0.0 basis
> > > > >> anyway.
> > > > >>
> > > > >> Not to confuse this thread but it makes me think we could do a
> similar
> > > > >> framing for a NiFi 3.0 which lays out a potentially new approach
> to
> > > > >> NiFi decoupling the web/interface from the runtime/operations and
> one
> > > > >> which is more fundamentally K8S based.  But we can cross that
> bridge a
> > > > >> bit later.  Does seem more and more like folks in the community
> would
> > > > >> like to know more about the potential directions we can go.
> > > > >>
> > > > >> Thanks!
> > > > >> Joe
> > > > >>
> > > > >> On Tue, Dec 6, 2022 at 1:53 PM David Handermann
> > > > >> <ex...@apache.org> wrote:
> > > > >>>
> > > > >>> Team,
> > > > >>>
> > > > >>> With the release of NiFi 1.19.0 deprecating support for Java 8,
> the
> > > end
> > > > >> of
> > > > >>> the year provides a good opportunity for finalizing general
> release
> > > goals
> > > > >>> for NiFi 2.0.
> > > > >>>
> > > > >>> Based on previous discussions from July 2021 [1] and June 2022
> [2],
> > > there
> > > > >>> seems to be general agreement with focusing a NiFi 2.0 release on
> > > > >> reducing
> > > > >>> technical debt while providing a straightforward upgrade path for
> > > current
> > > > >>> deployments.
> > > > >>>
> > > > >>> I have updated the NiFi 2.0 Proposed Release Goals [3] to reflect
> > > more
> > > > >>> recent progress in several areas. I also linked the Deprecated
> > > Components
> > > > >>> and Features [4] page outlining the current state of deprecated
> > > > >>> capabilities.
> > > > >>>
> > > > >>> The most recent update to the Proposed Release Goals outlines
> > > > >> implementing
> > > > >>> migration tooling to make the upgrade process as easy as
> possible.
> > > The
> > > > >>> addition of dedicated deprecation logging in NiFi 1.18.0 makes it
> > > easier
> > > > >> to
> > > > >>> warn of breaking changes, but the goal of migration tooling is to
> > > make it
> > > > >>> easier to upgrade configurations.
> > > > >>>
> > > > >>> The Proposed Release Goals does not include any release timelines
> > > right
> > > > >>> now, and we should anticipate supporting version 1 for a
> reasonable
> > > > >> period
> > > > >>> of time. As more and more libraries deprecate and drop support
> for
> > > Java
> > > > >> 8,
> > > > >>> it will become increasingly difficult to maintain a support
> branch,
> > > which
> > > > >>> is one of the main drivers behind a NiFi 2.0 release that drops
> > > support
> > > > >> for
> > > > >>> Java 8.
> > > > >>>
> > > > >>> The general development strategy should involve transitioning the
> > > main
> > > > >>> branch to a 2.0.0-SNAPSHOT version so new features and fixes
> will be
> > > > >>> targeted to the new version. Migration tooling will need to be
> > > > >> implemented
> > > > >>> on a version 1 support branch, and fixes can be backported where
> > > > >> possible,
> > > > >>> in preparation for subsequent version 1 releases.
> > > > >>>
> > > > >>> With that background, I would like to move to a formal vote soon,
> > > > >> changing
> > > > >>> the Proposed Release Goals document to Planned Release Goals.
> Please
> > > > >> weigh
> > > > >>> the general goals highlighted, and if there are no major
> roadblocks
> > > > >>> identified, I will follow up soon with a vote thread.
> > > > >>>
> > > > >>> Regards,
> > > > >>> David Handermann
> > > > >>>
> > > > >>> [1]
> https://lists.apache.org/thread/yj8scrdbx3pdo7990123mc03q24rn1m7
> > > > >>> [2]
> https://lists.apache.org/thread/mm1xf3b9nvrcgytb92oy3swvvc45fl34
> > > > >>> [3]
> > > > >>>
> > > > >>
> > >
> https://cwiki.apache.org/confluence/display/NIFI/NiFi+2.0+Proposed+Release+Goals
> > > > >>> [4]
> > > > >>>
> > > > >>
> > >
> https://cwiki.apache.org/confluence/display/NIFI/Deprecated+Components+and+Features
> > > > >>
> > > >
> > >
>

Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0

[Mike Thomsen <mi...@gmail.com>]

> Mike - what do you mean by "controller service-based configuration for

Using controller services for configuring bundles that connect an
external service such as Cassandra, Elasticsearch, etc. and removing
the option to configure connections on the processor.

> I don't think you were suggesting the minimum version be Java 17, were you?

I was. Partly as devil's advocate, partly because I actually want to
use Java 17 as a daily driver.

On Wed, Dec 7, 2022 at 2:20 PM Mark Bean <ma...@gmail.com> wrote:
>
> I agree this is a great start to a discussion with pointers to important
> docs for the 2.0 transition. Thanks David!
>
> Mike - what do you mean by "controller service-based configuration for
> connection details"?
>
> Also, the transition from Java 11 to 17 is not without potential issues.
> I've discovered one already. [1] I support stepping up on Java version
> requirements. Perhaps rather than the currently stated "Requires Java 8 or
> Java 11", the requirement can be "Requires Java 11 or Java 17". I don't
> think you were suggesting the minimum version be Java 17, were you? Either
> way, the issue with Java 17 needs to be identified and fixed as well as
> more thorough testing to find other possible edge cases before we move
> forward too aggressively.
>
> [1] https://issues.apache.org/jira/browse/NIFI-10958
>
> On Wed, Dec 7, 2022 at 1:33 PM Mike Thomsen <mi...@gmail.com> wrote:
>
> > Really good start on the discussion. One thing I'm curious about is
> > Java 11 vs 17. Java 8 -> 11 is major jump that I can understand why
> > businesses scoffed at that for a long time, but the lift from 11 to 17
> > was about like 7 -> 8. A 2.0 release seems like a good time to jump
> > straight to the latest official LTS for Java and start greenlighting
> > new language features that might simplify things.
> >
> > I would also add (since I didn't see it) a design goal of forcing a
> > complete shift in all bundles to using controller service-based
> > configurations for connection details. 2.0 feels like a really good
> > time for us to establish a community-wide best practice of
> > centralizing configurations in dedicated components.
> >
> > On Wed, Dec 7, 2022 at 9:13 AM Mark Payne <ma...@hotmail.com> wrote:
> > >
> > > Yeah, agreed. I am very supportive, as well.
> > >
> > > Thanks for taking the time to put this together, David.
> > >
> > > -Mark
> > >
> > >
> > > > On Dec 7, 2022, at 4:07 AM, Pierre Villard <
> > pierre.villard.fr@gmail.com> wrote:
> > > >
> > > > Thanks for putting this together David. This is an excellent writeup
> > and
> > > > it's great to have a release where we focus on tech debt as well as
> > making
> > > > sure we stay up to date with our dependencies and what we support.
> > This is
> > > > a great opportunity for us to clean a lot of things in our code and I
> > can't
> > > > wait for us to get started with this. I'm definitely a +1 to have a
> > formal
> > > > vote on this proposal.
> > > >
> > > > Thanks,
> > > > Pierre
> > > >
> > > > Le mar. 6 déc. 2022 à 23:50, Joe Witt <jo...@gmail.com> a écrit :
> > > >
> > > >> David, All,
> > > >>
> > > >> This is an excellent writeup/good framing.  I am supportive of this
> > > >> as-is since it is achievable and lays out a clear path.  We can make
> > > >> milestone releases of NiFi 2.0.0 along the way until we achieve all
> > > >> the stated goals. I assume migration bits will be the long pole and
> > > >> once we have them sorted we can kick out a 2.0.0.   We already have a
> > > >> version guide that governs how long we'd keep 1.x maintained though
> > > >> the phase out is pretty natural as we move main to a 2.0.0 basis
> > > >> anyway.
> > > >>
> > > >> Not to confuse this thread but it makes me think we could do a similar
> > > >> framing for a NiFi 3.0 which lays out a potentially new approach to
> > > >> NiFi decoupling the web/interface from the runtime/operations and one
> > > >> which is more fundamentally K8S based.  But we can cross that bridge a
> > > >> bit later.  Does seem more and more like folks in the community would
> > > >> like to know more about the potential directions we can go.
> > > >>
> > > >> Thanks!
> > > >> Joe
> > > >>
> > > >> On Tue, Dec 6, 2022 at 1:53 PM David Handermann
> > > >> <ex...@apache.org> wrote:
> > > >>>
> > > >>> Team,
> > > >>>
> > > >>> With the release of NiFi 1.19.0 deprecating support for Java 8, the
> > end
> > > >> of
> > > >>> the year provides a good opportunity for finalizing general release
> > goals
> > > >>> for NiFi 2.0.
> > > >>>
> > > >>> Based on previous discussions from July 2021 [1] and June 2022 [2],
> > there
> > > >>> seems to be general agreement with focusing a NiFi 2.0 release on
> > > >> reducing
> > > >>> technical debt while providing a straightforward upgrade path for
> > current
> > > >>> deployments.
> > > >>>
> > > >>> I have updated the NiFi 2.0 Proposed Release Goals [3] to reflect
> > more
> > > >>> recent progress in several areas. I also linked the Deprecated
> > Components
> > > >>> and Features [4] page outlining the current state of deprecated
> > > >>> capabilities.
> > > >>>
> > > >>> The most recent update to the Proposed Release Goals outlines
> > > >> implementing
> > > >>> migration tooling to make the upgrade process as easy as possible.
> > The
> > > >>> addition of dedicated deprecation logging in NiFi 1.18.0 makes it
> > easier
> > > >> to
> > > >>> warn of breaking changes, but the goal of migration tooling is to
> > make it
> > > >>> easier to upgrade configurations.
> > > >>>
> > > >>> The Proposed Release Goals does not include any release timelines
> > right
> > > >>> now, and we should anticipate supporting version 1 for a reasonable
> > > >> period
> > > >>> of time. As more and more libraries deprecate and drop support for
> > Java
> > > >> 8,
> > > >>> it will become increasingly difficult to maintain a support branch,
> > which
> > > >>> is one of the main drivers behind a NiFi 2.0 release that drops
> > support
> > > >> for
> > > >>> Java 8.
> > > >>>
> > > >>> The general development strategy should involve transitioning the
> > main
> > > >>> branch to a 2.0.0-SNAPSHOT version so new features and fixes will be
> > > >>> targeted to the new version. Migration tooling will need to be
> > > >> implemented
> > > >>> on a version 1 support branch, and fixes can be backported where
> > > >> possible,
> > > >>> in preparation for subsequent version 1 releases.
> > > >>>
> > > >>> With that background, I would like to move to a formal vote soon,
> > > >> changing
> > > >>> the Proposed Release Goals document to Planned Release Goals. Please
> > > >> weigh
> > > >>> the general goals highlighted, and if there are no major roadblocks
> > > >>> identified, I will follow up soon with a vote thread.
> > > >>>
> > > >>> Regards,
> > > >>> David Handermann
> > > >>>
> > > >>> [1] https://lists.apache.org/thread/yj8scrdbx3pdo7990123mc03q24rn1m7
> > > >>> [2] https://lists.apache.org/thread/mm1xf3b9nvrcgytb92oy3swvvc45fl34
> > > >>> [3]
> > > >>>
> > > >>
> > https://cwiki.apache.org/confluence/display/NIFI/NiFi+2.0+Proposed+Release+Goals
> > > >>> [4]
> > > >>>
> > > >>
> > https://cwiki.apache.org/confluence/display/NIFI/Deprecated+Components+and+Features
> > > >>
> > >
> >

Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0

[Mark Bean <ma...@gmail.com>]

I agree this is a great start to a discussion with pointers to important
docs for the 2.0 transition. Thanks David!

Mike - what do you mean by "controller service-based configuration for
connection details"?

Also, the transition from Java 11 to 17 is not without potential issues.
I've discovered one already. [1] I support stepping up on Java version
requirements. Perhaps rather than the currently stated "Requires Java 8 or
Java 11", the requirement can be "Requires Java 11 or Java 17". I don't
think you were suggesting the minimum version be Java 17, were you? Either
way, the issue with Java 17 needs to be identified and fixed as well as
more thorough testing to find other possible edge cases before we move
forward too aggressively.

[1] https://issues.apache.org/jira/browse/NIFI-10958

On Wed, Dec 7, 2022 at 1:33 PM Mike Thomsen <mi...@gmail.com> wrote:

> Really good start on the discussion. One thing I'm curious about is
> Java 11 vs 17. Java 8 -> 11 is major jump that I can understand why
> businesses scoffed at that for a long time, but the lift from 11 to 17
> was about like 7 -> 8. A 2.0 release seems like a good time to jump
> straight to the latest official LTS for Java and start greenlighting
> new language features that might simplify things.
>
> I would also add (since I didn't see it) a design goal of forcing a
> complete shift in all bundles to using controller service-based
> configurations for connection details. 2.0 feels like a really good
> time for us to establish a community-wide best practice of
> centralizing configurations in dedicated components.
>
> On Wed, Dec 7, 2022 at 9:13 AM Mark Payne <ma...@hotmail.com> wrote:
> >
> > Yeah, agreed. I am very supportive, as well.
> >
> > Thanks for taking the time to put this together, David.
> >
> > -Mark
> >
> >
> > > On Dec 7, 2022, at 4:07 AM, Pierre Villard <
> pierre.villard.fr@gmail.com> wrote:
> > >
> > > Thanks for putting this together David. This is an excellent writeup
> and
> > > it's great to have a release where we focus on tech debt as well as
> making
> > > sure we stay up to date with our dependencies and what we support.
> This is
> > > a great opportunity for us to clean a lot of things in our code and I
> can't
> > > wait for us to get started with this. I'm definitely a +1 to have a
> formal
> > > vote on this proposal.
> > >
> > > Thanks,
> > > Pierre
> > >
> > > Le mar. 6 déc. 2022 à 23:50, Joe Witt <jo...@gmail.com> a écrit :
> > >
> > >> David, All,
> > >>
> > >> This is an excellent writeup/good framing.  I am supportive of this
> > >> as-is since it is achievable and lays out a clear path.  We can make
> > >> milestone releases of NiFi 2.0.0 along the way until we achieve all
> > >> the stated goals. I assume migration bits will be the long pole and
> > >> once we have them sorted we can kick out a 2.0.0.   We already have a
> > >> version guide that governs how long we'd keep 1.x maintained though
> > >> the phase out is pretty natural as we move main to a 2.0.0 basis
> > >> anyway.
> > >>
> > >> Not to confuse this thread but it makes me think we could do a similar
> > >> framing for a NiFi 3.0 which lays out a potentially new approach to
> > >> NiFi decoupling the web/interface from the runtime/operations and one
> > >> which is more fundamentally K8S based.  But we can cross that bridge a
> > >> bit later.  Does seem more and more like folks in the community would
> > >> like to know more about the potential directions we can go.
> > >>
> > >> Thanks!
> > >> Joe
> > >>
> > >> On Tue, Dec 6, 2022 at 1:53 PM David Handermann
> > >> <ex...@apache.org> wrote:
> > >>>
> > >>> Team,
> > >>>
> > >>> With the release of NiFi 1.19.0 deprecating support for Java 8, the
> end
> > >> of
> > >>> the year provides a good opportunity for finalizing general release
> goals
> > >>> for NiFi 2.0.
> > >>>
> > >>> Based on previous discussions from July 2021 [1] and June 2022 [2],
> there
> > >>> seems to be general agreement with focusing a NiFi 2.0 release on
> > >> reducing
> > >>> technical debt while providing a straightforward upgrade path for
> current
> > >>> deployments.
> > >>>
> > >>> I have updated the NiFi 2.0 Proposed Release Goals [3] to reflect
> more
> > >>> recent progress in several areas. I also linked the Deprecated
> Components
> > >>> and Features [4] page outlining the current state of deprecated
> > >>> capabilities.
> > >>>
> > >>> The most recent update to the Proposed Release Goals outlines
> > >> implementing
> > >>> migration tooling to make the upgrade process as easy as possible.
> The
> > >>> addition of dedicated deprecation logging in NiFi 1.18.0 makes it
> easier
> > >> to
> > >>> warn of breaking changes, but the goal of migration tooling is to
> make it
> > >>> easier to upgrade configurations.
> > >>>
> > >>> The Proposed Release Goals does not include any release timelines
> right
> > >>> now, and we should anticipate supporting version 1 for a reasonable
> > >> period
> > >>> of time. As more and more libraries deprecate and drop support for
> Java
> > >> 8,
> > >>> it will become increasingly difficult to maintain a support branch,
> which
> > >>> is one of the main drivers behind a NiFi 2.0 release that drops
> support
> > >> for
> > >>> Java 8.
> > >>>
> > >>> The general development strategy should involve transitioning the
> main
> > >>> branch to a 2.0.0-SNAPSHOT version so new features and fixes will be
> > >>> targeted to the new version. Migration tooling will need to be
> > >> implemented
> > >>> on a version 1 support branch, and fixes can be backported where
> > >> possible,
> > >>> in preparation for subsequent version 1 releases.
> > >>>
> > >>> With that background, I would like to move to a formal vote soon,
> > >> changing
> > >>> the Proposed Release Goals document to Planned Release Goals. Please
> > >> weigh
> > >>> the general goals highlighted, and if there are no major roadblocks
> > >>> identified, I will follow up soon with a vote thread.
> > >>>
> > >>> Regards,
> > >>> David Handermann
> > >>>
> > >>> [1] https://lists.apache.org/thread/yj8scrdbx3pdo7990123mc03q24rn1m7
> > >>> [2] https://lists.apache.org/thread/mm1xf3b9nvrcgytb92oy3swvvc45fl34
> > >>> [3]
> > >>>
> > >>
> https://cwiki.apache.org/confluence/display/NIFI/NiFi+2.0+Proposed+Release+Goals
> > >>> [4]
> > >>>
> > >>
> https://cwiki.apache.org/confluence/display/NIFI/Deprecated+Components+and+Features
> > >>
> >
>

Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0

[Mike Thomsen <mi...@gmail.com>]

Really good start on the discussion. One thing I'm curious about is
Java 11 vs 17. Java 8 -> 11 is major jump that I can understand why
businesses scoffed at that for a long time, but the lift from 11 to 17
was about like 7 -> 8. A 2.0 release seems like a good time to jump
straight to the latest official LTS for Java and start greenlighting
new language features that might simplify things.

I would also add (since I didn't see it) a design goal of forcing a
complete shift in all bundles to using controller service-based
configurations for connection details. 2.0 feels like a really good
time for us to establish a community-wide best practice of
centralizing configurations in dedicated components.

On Wed, Dec 7, 2022 at 9:13 AM Mark Payne <ma...@hotmail.com> wrote:
>
> Yeah, agreed. I am very supportive, as well.
>
> Thanks for taking the time to put this together, David.
>
> -Mark
>
>
> > On Dec 7, 2022, at 4:07 AM, Pierre Villard <pi...@gmail.com> wrote:
> >
> > Thanks for putting this together David. This is an excellent writeup and
> > it's great to have a release where we focus on tech debt as well as making
> > sure we stay up to date with our dependencies and what we support. This is
> > a great opportunity for us to clean a lot of things in our code and I can't
> > wait for us to get started with this. I'm definitely a +1 to have a formal
> > vote on this proposal.
> >
> > Thanks,
> > Pierre
> >
> > Le mar. 6 déc. 2022 à 23:50, Joe Witt <jo...@gmail.com> a écrit :
> >
> >> David, All,
> >>
> >> This is an excellent writeup/good framing.  I am supportive of this
> >> as-is since it is achievable and lays out a clear path.  We can make
> >> milestone releases of NiFi 2.0.0 along the way until we achieve all
> >> the stated goals. I assume migration bits will be the long pole and
> >> once we have them sorted we can kick out a 2.0.0.   We already have a
> >> version guide that governs how long we'd keep 1.x maintained though
> >> the phase out is pretty natural as we move main to a 2.0.0 basis
> >> anyway.
> >>
> >> Not to confuse this thread but it makes me think we could do a similar
> >> framing for a NiFi 3.0 which lays out a potentially new approach to
> >> NiFi decoupling the web/interface from the runtime/operations and one
> >> which is more fundamentally K8S based.  But we can cross that bridge a
> >> bit later.  Does seem more and more like folks in the community would
> >> like to know more about the potential directions we can go.
> >>
> >> Thanks!
> >> Joe
> >>
> >> On Tue, Dec 6, 2022 at 1:53 PM David Handermann
> >> <ex...@apache.org> wrote:
> >>>
> >>> Team,
> >>>
> >>> With the release of NiFi 1.19.0 deprecating support for Java 8, the end
> >> of
> >>> the year provides a good opportunity for finalizing general release goals
> >>> for NiFi 2.0.
> >>>
> >>> Based on previous discussions from July 2021 [1] and June 2022 [2], there
> >>> seems to be general agreement with focusing a NiFi 2.0 release on
> >> reducing
> >>> technical debt while providing a straightforward upgrade path for current
> >>> deployments.
> >>>
> >>> I have updated the NiFi 2.0 Proposed Release Goals [3] to reflect more
> >>> recent progress in several areas. I also linked the Deprecated Components
> >>> and Features [4] page outlining the current state of deprecated
> >>> capabilities.
> >>>
> >>> The most recent update to the Proposed Release Goals outlines
> >> implementing
> >>> migration tooling to make the upgrade process as easy as possible. The
> >>> addition of dedicated deprecation logging in NiFi 1.18.0 makes it easier
> >> to
> >>> warn of breaking changes, but the goal of migration tooling is to make it
> >>> easier to upgrade configurations.
> >>>
> >>> The Proposed Release Goals does not include any release timelines right
> >>> now, and we should anticipate supporting version 1 for a reasonable
> >> period
> >>> of time. As more and more libraries deprecate and drop support for Java
> >> 8,
> >>> it will become increasingly difficult to maintain a support branch, which
> >>> is one of the main drivers behind a NiFi 2.0 release that drops support
> >> for
> >>> Java 8.
> >>>
> >>> The general development strategy should involve transitioning the main
> >>> branch to a 2.0.0-SNAPSHOT version so new features and fixes will be
> >>> targeted to the new version. Migration tooling will need to be
> >> implemented
> >>> on a version 1 support branch, and fixes can be backported where
> >> possible,
> >>> in preparation for subsequent version 1 releases.
> >>>
> >>> With that background, I would like to move to a formal vote soon,
> >> changing
> >>> the Proposed Release Goals document to Planned Release Goals. Please
> >> weigh
> >>> the general goals highlighted, and if there are no major roadblocks
> >>> identified, I will follow up soon with a vote thread.
> >>>
> >>> Regards,
> >>> David Handermann
> >>>
> >>> [1] https://lists.apache.org/thread/yj8scrdbx3pdo7990123mc03q24rn1m7
> >>> [2] https://lists.apache.org/thread/mm1xf3b9nvrcgytb92oy3swvvc45fl34
> >>> [3]
> >>>
> >> https://cwiki.apache.org/confluence/display/NIFI/NiFi+2.0+Proposed+Release+Goals
> >>> [4]
> >>>
> >> https://cwiki.apache.org/confluence/display/NIFI/Deprecated+Components+and+Features
> >>
>

Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0

[Mark Payne <ma...@hotmail.com>]

Yeah, agreed. I am very supportive, as well.

Thanks for taking the time to put this together, David.

-Mark


> On Dec 7, 2022, at 4:07 AM, Pierre Villard <pi...@gmail.com> wrote:
> 
> Thanks for putting this together David. This is an excellent writeup and
> it's great to have a release where we focus on tech debt as well as making
> sure we stay up to date with our dependencies and what we support. This is
> a great opportunity for us to clean a lot of things in our code and I can't
> wait for us to get started with this. I'm definitely a +1 to have a formal
> vote on this proposal.
> 
> Thanks,
> Pierre
> 
> Le mar. 6 déc. 2022 à 23:50, Joe Witt <jo...@gmail.com> a écrit :
> 
>> David, All,
>> 
>> This is an excellent writeup/good framing.  I am supportive of this
>> as-is since it is achievable and lays out a clear path.  We can make
>> milestone releases of NiFi 2.0.0 along the way until we achieve all
>> the stated goals. I assume migration bits will be the long pole and
>> once we have them sorted we can kick out a 2.0.0.   We already have a
>> version guide that governs how long we'd keep 1.x maintained though
>> the phase out is pretty natural as we move main to a 2.0.0 basis
>> anyway.
>> 
>> Not to confuse this thread but it makes me think we could do a similar
>> framing for a NiFi 3.0 which lays out a potentially new approach to
>> NiFi decoupling the web/interface from the runtime/operations and one
>> which is more fundamentally K8S based.  But we can cross that bridge a
>> bit later.  Does seem more and more like folks in the community would
>> like to know more about the potential directions we can go.
>> 
>> Thanks!
>> Joe
>> 
>> On Tue, Dec 6, 2022 at 1:53 PM David Handermann
>> <ex...@apache.org> wrote:
>>> 
>>> Team,
>>> 
>>> With the release of NiFi 1.19.0 deprecating support for Java 8, the end
>> of
>>> the year provides a good opportunity for finalizing general release goals
>>> for NiFi 2.0.
>>> 
>>> Based on previous discussions from July 2021 [1] and June 2022 [2], there
>>> seems to be general agreement with focusing a NiFi 2.0 release on
>> reducing
>>> technical debt while providing a straightforward upgrade path for current
>>> deployments.
>>> 
>>> I have updated the NiFi 2.0 Proposed Release Goals [3] to reflect more
>>> recent progress in several areas. I also linked the Deprecated Components
>>> and Features [4] page outlining the current state of deprecated
>>> capabilities.
>>> 
>>> The most recent update to the Proposed Release Goals outlines
>> implementing
>>> migration tooling to make the upgrade process as easy as possible. The
>>> addition of dedicated deprecation logging in NiFi 1.18.0 makes it easier
>> to
>>> warn of breaking changes, but the goal of migration tooling is to make it
>>> easier to upgrade configurations.
>>> 
>>> The Proposed Release Goals does not include any release timelines right
>>> now, and we should anticipate supporting version 1 for a reasonable
>> period
>>> of time. As more and more libraries deprecate and drop support for Java
>> 8,
>>> it will become increasingly difficult to maintain a support branch, which
>>> is one of the main drivers behind a NiFi 2.0 release that drops support
>> for
>>> Java 8.
>>> 
>>> The general development strategy should involve transitioning the main
>>> branch to a 2.0.0-SNAPSHOT version so new features and fixes will be
>>> targeted to the new version. Migration tooling will need to be
>> implemented
>>> on a version 1 support branch, and fixes can be backported where
>> possible,
>>> in preparation for subsequent version 1 releases.
>>> 
>>> With that background, I would like to move to a formal vote soon,
>> changing
>>> the Proposed Release Goals document to Planned Release Goals. Please
>> weigh
>>> the general goals highlighted, and if there are no major roadblocks
>>> identified, I will follow up soon with a vote thread.
>>> 
>>> Regards,
>>> David Handermann
>>> 
>>> [1] https://lists.apache.org/thread/yj8scrdbx3pdo7990123mc03q24rn1m7
>>> [2] https://lists.apache.org/thread/mm1xf3b9nvrcgytb92oy3swvvc45fl34
>>> [3]
>>> 
>> https://cwiki.apache.org/confluence/display/NIFI/NiFi+2.0+Proposed+Release+Goals
>>> [4]
>>> 
>> https://cwiki.apache.org/confluence/display/NIFI/Deprecated+Components+and+Features
>> 

Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0

[Pierre Villard <pi...@gmail.com>]

Thanks for putting this together David. This is an excellent writeup and
it's great to have a release where we focus on tech debt as well as making
sure we stay up to date with our dependencies and what we support. This is
a great opportunity for us to clean a lot of things in our code and I can't
wait for us to get started with this. I'm definitely a +1 to have a formal
vote on this proposal.

Thanks,
Pierre

Le mar. 6 déc. 2022 à 23:50, Joe Witt <jo...@gmail.com> a écrit :

> David, All,
>
> This is an excellent writeup/good framing.  I am supportive of this
> as-is since it is achievable and lays out a clear path.  We can make
> milestone releases of NiFi 2.0.0 along the way until we achieve all
> the stated goals. I assume migration bits will be the long pole and
> once we have them sorted we can kick out a 2.0.0.   We already have a
> version guide that governs how long we'd keep 1.x maintained though
> the phase out is pretty natural as we move main to a 2.0.0 basis
> anyway.
>
> Not to confuse this thread but it makes me think we could do a similar
> framing for a NiFi 3.0 which lays out a potentially new approach to
> NiFi decoupling the web/interface from the runtime/operations and one
> which is more fundamentally K8S based.  But we can cross that bridge a
> bit later.  Does seem more and more like folks in the community would
> like to know more about the potential directions we can go.
>
> Thanks!
> Joe
>
> On Tue, Dec 6, 2022 at 1:53 PM David Handermann
> <ex...@apache.org> wrote:
> >
> > Team,
> >
> > With the release of NiFi 1.19.0 deprecating support for Java 8, the end
> of
> > the year provides a good opportunity for finalizing general release goals
> > for NiFi 2.0.
> >
> > Based on previous discussions from July 2021 [1] and June 2022 [2], there
> > seems to be general agreement with focusing a NiFi 2.0 release on
> reducing
> > technical debt while providing a straightforward upgrade path for current
> > deployments.
> >
> > I have updated the NiFi 2.0 Proposed Release Goals [3] to reflect more
> > recent progress in several areas. I also linked the Deprecated Components
> > and Features [4] page outlining the current state of deprecated
> > capabilities.
> >
> > The most recent update to the Proposed Release Goals outlines
> implementing
> > migration tooling to make the upgrade process as easy as possible. The
> > addition of dedicated deprecation logging in NiFi 1.18.0 makes it easier
> to
> > warn of breaking changes, but the goal of migration tooling is to make it
> > easier to upgrade configurations.
> >
> > The Proposed Release Goals does not include any release timelines right
> > now, and we should anticipate supporting version 1 for a reasonable
> period
> > of time. As more and more libraries deprecate and drop support for Java
> 8,
> > it will become increasingly difficult to maintain a support branch, which
> > is one of the main drivers behind a NiFi 2.0 release that drops support
> for
> > Java 8.
> >
> > The general development strategy should involve transitioning the main
> > branch to a 2.0.0-SNAPSHOT version so new features and fixes will be
> > targeted to the new version. Migration tooling will need to be
> implemented
> > on a version 1 support branch, and fixes can be backported where
> possible,
> > in preparation for subsequent version 1 releases.
> >
> > With that background, I would like to move to a formal vote soon,
> changing
> > the Proposed Release Goals document to Planned Release Goals. Please
> weigh
> > the general goals highlighted, and if there are no major roadblocks
> > identified, I will follow up soon with a vote thread.
> >
> > Regards,
> > David Handermann
> >
> > [1] https://lists.apache.org/thread/yj8scrdbx3pdo7990123mc03q24rn1m7
> > [2] https://lists.apache.org/thread/mm1xf3b9nvrcgytb92oy3swvvc45fl34
> > [3]
> >
> https://cwiki.apache.org/confluence/display/NIFI/NiFi+2.0+Proposed+Release+Goals
> > [4]
> >
> https://cwiki.apache.org/confluence/display/NIFI/Deprecated+Components+and+Features
>

Re: [DISCUSS] Finalizing Release Goals for NiFi 2.0

[Joe Witt <jo...@gmail.com>]

David, All,

This is an excellent writeup/good framing.  I am supportive of this
as-is since it is achievable and lays out a clear path.  We can make
milestone releases of NiFi 2.0.0 along the way until we achieve all
the stated goals. I assume migration bits will be the long pole and
once we have them sorted we can kick out a 2.0.0.   We already have a
version guide that governs how long we'd keep 1.x maintained though
the phase out is pretty natural as we move main to a 2.0.0 basis
anyway.

Not to confuse this thread but it makes me think we could do a similar
framing for a NiFi 3.0 which lays out a potentially new approach to
NiFi decoupling the web/interface from the runtime/operations and one
which is more fundamentally K8S based.  But we can cross that bridge a
bit later.  Does seem more and more like folks in the community would
like to know more about the potential directions we can go.

Thanks!
Joe

On Tue, Dec 6, 2022 at 1:53 PM David Handermann
<ex...@apache.org> wrote:
>
> Team,
>
> With the release of NiFi 1.19.0 deprecating support for Java 8, the end of
> the year provides a good opportunity for finalizing general release goals
> for NiFi 2.0.
>
> Based on previous discussions from July 2021 [1] and June 2022 [2], there
> seems to be general agreement with focusing a NiFi 2.0 release on reducing
> technical debt while providing a straightforward upgrade path for current
> deployments.
>
> I have updated the NiFi 2.0 Proposed Release Goals [3] to reflect more
> recent progress in several areas. I also linked the Deprecated Components
> and Features [4] page outlining the current state of deprecated
> capabilities.
>
> The most recent update to the Proposed Release Goals outlines implementing
> migration tooling to make the upgrade process as easy as possible. The
> addition of dedicated deprecation logging in NiFi 1.18.0 makes it easier to
> warn of breaking changes, but the goal of migration tooling is to make it
> easier to upgrade configurations.
>
> The Proposed Release Goals does not include any release timelines right
> now, and we should anticipate supporting version 1 for a reasonable period
> of time. As more and more libraries deprecate and drop support for Java 8,
> it will become increasingly difficult to maintain a support branch, which
> is one of the main drivers behind a NiFi 2.0 release that drops support for
> Java 8.
>
> The general development strategy should involve transitioning the main
> branch to a 2.0.0-SNAPSHOT version so new features and fixes will be
> targeted to the new version. Migration tooling will need to be implemented
> on a version 1 support branch, and fixes can be backported where possible,
> in preparation for subsequent version 1 releases.
>
> With that background, I would like to move to a formal vote soon, changing
> the Proposed Release Goals document to Planned Release Goals. Please weigh
> the general goals highlighted, and if there are no major roadblocks
> identified, I will follow up soon with a vote thread.
>
> Regards,
> David Handermann
>
> [1] https://lists.apache.org/thread/yj8scrdbx3pdo7990123mc03q24rn1m7
> [2] https://lists.apache.org/thread/mm1xf3b9nvrcgytb92oy3swvvc45fl34
> [3]
> https://cwiki.apache.org/confluence/display/NIFI/NiFi+2.0+Proposed+Release+Goals
> [4]
> https://cwiki.apache.org/confluence/display/NIFI/Deprecated+Components+and+Features