The EOL discussion is not here because we have a new problem. It is here because we finally have an answer.
The inability to address reported vulnerabilities or fundamental end of life status for key underlying components in the 1.x line is a problem that was fully recognized three years ago. In that time we created a plan for what NiFi 2.0 would be and how we'd manage both maintaining the 1.x line while building to the 2.x GA. In the past year we've conducted four milestone releases of NiFi 2.x and we've continued putting out feature, bug fix, and security improvement releases of 1.x. Feature bearing releases of 1.x are no longer appropriate as 2.x is here and GA and that was the plan all along. Bug fixes are still reasonable in spirit but you need people to submit the JIRAs, fix the JIRAs, peer review the changes, and to conduct releases and make votes. That is in increasingly short supply as it has been quite the task splitting attention across two major lines and naturally developers and users will gravitate toward the go forward path. Vulnerability/Security related considerations are where things are fundamentally problematic. We had a security report today about the super old/outdated front-end libraries we use in 1.x. That won't change. We had a report last week about Spring libraries needing updated except you can't unless you have Pivotal support so not an option. Those won't change. We have had questions around Jetty changes but that is tied to Java 8. We've had questions about Java 8 being end of life and even Java 11 and even now Java 17 in terms of its codebase permissive licensing changing. The things we can reasonably address in the 1.x line are getting smaller and smaller and the time required to address any new thing is higher and higher. We as a community, regardless of good intentions, cannot fix the illities of the 1.x line and thus the 2.x line is here. The 1.x line will absolutely continue to atrophy and it will accelerate. If we do not signal EOL on 1.x that means we're saying we can keep fixing problems. While that is true for bugs, that is not true for vulnerabilities broadly and for our most critical components. If you still fix bugs people assume this means you still reasonably fix vulnerabilities/etc.. And unless we declare EOL on the 1.x line we will continue to get non-serviceable reports and mislead the user base. The answer is to clearly signal that users should transition to the 2.x line and focus our help on answering questions people might have on how to do that. I am supportive of EOL for the 1.x line. I also like the poetic nature of the decade timing. On Mon, Nov 4, 2024 at 2:47 PM David Handermann <exceptionfact...@apache.org> wrote: > Mike, > > Thanks for the reply and thoughts on the timing, there is something to > be said for a December 8, 2024 date given the 10 year anniversary. > > Regards, > David Handermann > > On Mon, Nov 4, 2024 at 3:32 PM Michael Moser <moser...@gmail.com> wrote: > > > > I agree with reducing support for the 1.x branch down to no longer > allow > > new features. I don't think we should discontinue accepting bug fixes, > > though. We don't know if bugs will be found early in the life cycle of > > the new features in 1.28.0. > > > > I would like to see one last release, called 1.28.1 and I think we should > > give it more than 5 weeks of time. Perhaps January 31, 2025 would be a > > better target? Though I just had a thought that December 8, 2024 would > be > > exactly 10 years after the very first commit for the initial code > > contribution, and that would be satisfyingly poetic. > > > > -- Mike > > > > > > On Mon, Nov 4, 2024 at 4:27 PM Russell Bateman <r...@windofkeltia.com> > > wrote: > > > > > Folks, > > > > > > I understand the assertions based on Spring, Jetty and Angular. Those > > > are what they are. And no new features are fine by me. Deprecation of > > > existing or cautionary features are fine by me. > > > > > > However, I'm going to have trouble convincing my management to continue > > > considering NiFi in our product when I reveal to them that one scant > > > week has elapsed since the last version (1.28.0), but that now the > whole > > > product's reached end-of-life. It seems a strong indictment of Apache > > > NiFi to drop 2.0.0 only to say on the same day that there's no grace > > > period for users to adopt a /major version dot 0/. While I may not > > > myself have been paying serious enough attention to NiFi 2 (except to > > > install and run it for some time now to make certain of no surprises), > I > > > feel like rev'ing 1.25.0's third number a couple of dozen (so, for > > > nearly a full year) might have delivered more the message, "get quickly > > > off 1.x 'cause it's dead by year's end." Even with a year's notice, > we'd > > > have a struggle to get our customers off of 1.x. > > > > > > Maybe it's just that the message needs more palatable crafting? > > > > > > "As we cannot provide security support for NiFi 1.x, [we] should > > > discontinue accepting patches for bug fixes." (I can spin that) > > > > > > "I propose November 30, *2024* as the official date for declaring > > > NiFi 1.x at end of life." (frightening way to say this) > > > > > > I could have spent a little more time thinking about this and crafting > > > my contribution to this discussion, but I hope I'm making my point > > > usefully. > > > > > > Russ Bateman > > > > > > > > > On 11/4/24 13:44, David Handermann wrote: > > > > Team, > > > > > > > > Following the four milestone versions and the general availability of > > > > NiFi 2.0.0, we should determine the timing to discontinue support for > > > > NiFi 1. > > > > > > > > Although this comes right after the release of NiFi 2.0.0, the > reality > > > > is that that support branch already has several fundamental > > > > dependencies that are no longer supported. These unsupported core > > > > dependencies include: > > > > > > > > - Spring 5 as of 2024-08-31 [1] > > > > - Jetty 9.4 as of 2022-06-01 [2] > > > > - Angular 1.8 as of 2021-12-01 [3] > > > > > > > > [1]https://endoflife.date/spring-framework > > > > [2]https://endoflife.date/eclipse-jetty > > > > [3]https://endoflife.date/angularjs > > > > > > > > There are other component dependencies to consider, but the above > > > > dependencies are important because they are foundational to the > > > > application. The last open source version of Spring 5.3 already has > > > > one associated CVE, and although it does not impact NiFi directly, it > > > > is just one of a growing number of security issues that cannot be > > > > resolved. > > > > > > > > As we cannot provide security support for NiFi 1, which should > > > > discontinue accepting patches for bug fixes. > > > > > > > > Although it may be worth considering one more patch-level release as > > > > 1.28.1 before declaring NiFi 1 EOL, we should not consider any new > > > > features. > > > > > > > > To move the discussion in a concrete direction, I propose November > 30, > > > > 2024 as the official date for declaring NiFi 1 EOL. > > > > > > > > Regards, > > > > David Handermann > > > >
