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
