Hi all, I understand the reasons to declare an EOL quickly, given the external dependencies, but like Russell said before the short notice is going to cause trouble with our bigger corporate customers. It would have been nice to have the EOL date announced about a year ago, even if it had been a provisional one. The more you can delay it now, the less credibility I (and NiFi itself) lose :-\
I've been pushing since the first announcement of NiFi 2.0 for our customers to prepare. The smaller NiFi instances are all prepared. But there are also big customers with hundreds of flows that depend on variables and XML templates, and as you can imagine this was never a priority for them without either a NiFi 2.0 GA to move to or an actual EOL date to get security officers upping the priority. Now we have a GA release finally, but corporate Q4 plans are set in stone and Q1 2025 plans are already filling up. Telling the customers' development teams to upend their plans and tell their business customers to forget deliveries because NiFi needs to be fixed ASAP is probably not going to fly and instead going to seriously dent NiFi's reputation and position. Unless we can automate the flow migration process it's going to be a year-long migration at least. That said, are there any tools or scripts to make the migration smoother? Configuring multiple levels of parameter contexts with inheritance is a labor-intensive process if we are to mirror the current setup with variables being inherited from main canvas, team PG, subject PG and flow PG, etc. Anything that could go through the process groups and configure this automatically would be greatly appreciated. I will look into that myself too, but anything helps really. Regards, Isha -----Oorspronkelijk bericht----- Van: Joe Witt <joe.w...@gmail.com> Verzonden: maandag 4 november 2024 23:44 Aan: dev@nifi.apache.org Onderwerp: Re: [DISCUSS] End-of-life timing for NiFi 1 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:
