> 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 <mark.o.b...@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 <mikerthom...@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 <marka...@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...@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 <joe.w...@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 > > > >> <exceptionfact...@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 > > > >> > > > > >
