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 <mikerthom...@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 <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 > > > > >> > > > > > > > >
