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 > >> >
