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 >
