Team, Having discussed phrasing options, it looks like we are close to being ready for a formal vote. Building on several suggestions, I think the vote should be on the following points:
1. NiFi version 1 is declared End of Support as of December 8, 2024. End of Support means no additional features will be accepted for version 1, and no future releases are planned. The project management committee may consider critical bug fixes for essential framework features on an exceptional basis. Critical bug fixes do not include upgrading project dependencies. 2. Add the following statement to the Download page: --- Apache NiFi 1.28 is the last minor release of the version 1 series. The project management committee may consider critical bug fixes to essential framework features on an exceptional basis. Critical bug fixes do not include upgrading project dependencies. The project notes that multiple fundamental dependencies in the version 1 series cannot be upgraded. These dependencies include Jetty 9, Spring 5, and Angular 1.8. The Apache NiFi team strongly encourages users to upgrade to NiFi 2. --- The key point is that critical bug fixes do not cover project dependencies, because that is not an option in general. The "may consider" and "exceptional basis" wording leaves open the theoretical possibility of finding and fixing some substantial issue in the NiFi framework itself, but it avoids implying any kind of commitment to future changes. In absence of any substantive disagreements on the above wording, I will plan on initiating a vote thread tomorrow afternoon. Regards, David Handermann On Fri, Nov 8, 2024 at 10:18 AM Mike Thomsen <mikerthom...@gmail.com> wrote: > > Isha and Russ, > > It might be tactically advantageous to explain this to your clients and > leadership by focusing on the Spring angle because a lot of Java developers > got slammed with this, so it may be a very relatable issue for them. > > On Fri, Nov 8, 2024 at 3:41 AM Isha Lamboo <isha.lam...@virtualsciences.nl> > wrote: > > > For what it's worth, I agree with David. This clearly is End of Life, so > > let's not mince words. Anything else would be a disservice to the community. > > > > Thanks all for painting a clearer picture of why it's not doable or > > possible license-wise to promise continued support. > > > > I'm off to figure out a mapping from inherited variables to inherited > > parameter contexts and probably contact some vendors to see what their > > support will look like. > > > > Thanks, > > > > Isha > > > > -----Oorspronkelijk bericht----- > > Van: Joe Witt <joe.w...@gmail.com> > > Verzonden: donderdag 7 november 2024 21:47 > > Aan: dev@nifi.apache.org > > Onderwerp: Re: [DISCUSS] End-of-life timing for NiFi 1 > > > > I'll avoid sharing more thoughts for now. I've shared enough. But I am > > directionally on page with what Handermann/Moser just wrote. > > > > Thanks > > > > On Thu, Nov 7, 2024 at 1:33 PM David Handermann < > > exceptionfact...@apache.org> > > wrote: > > > > > I appreciate the sensitivity around end-of-life wording, but it is > > > important to send a clear message. > > > > > > The project cannot provide security-related updates because the > > > fundamental dependencies are already end-of-life: Jetty 9, Spring 5, > > > and AngularJS 1.8. > > > > > > To provide any type of statement that implies future support would be > > > inaccurate and misleading. We also need to provide a specific date in > > > the short term to make it clear that we will not be accepting or > > > backporting changes. > > > > > > The project management committee is responsible for handling releases > > > and security findings, and as such, we need to make it clear what we > > > can support. Although we might consider a rare exception for some > > > fundamental framework bug not previously known, that should not be > > > posted as an expressed or implied support for a future version. > > > > > > I'm open to calling it "end of development" or "end of support", but > > > we should avoid semantics that obscure the reality. > > > > > > Regards, > > > David Handermann > > > > > > On Thu, Nov 7, 2024 at 2:11 PM Michael Moser <moser...@gmail.com> wrote: > > > > > > > > I believe many people place a certain meaning on the End-Of-Life > > > > label, interpreting it as "software that has reached EOL shall not > > > > be used". I don't think that's the message we want to send about > > > > 1.28 so soon after > > > the > > > > 2.0.0 release. > > > > > > > > I like Mike's suggestion of End of Development for 1.x and I concur > > > > to remove the End Of Life/End Of Support words from Joe's #1 point. > > > > There > > > are > > > > hidden meanings we won't fully comprehend. I recommend not even > > > specifying > > > > a future EOL date, because nobody will be happy with 30 days from > > > > now > > > (too > > > > soon) and many will be unhappy with 12 months from now (too long to > > > promise > > > > resources to). > > > > > > > > I propose these words for Joe's #3 point on the downloads page. > > > > > > > > "Apache NiFi 1.28 will be the last minor version release in the 1.x > > > > baseline. For the near future, only significant bug fixes and > > > > security related updates will be considered for future patch > > > > releases. The Apache NiFi team wishes to inform the community, > > > > however, that several dependencies in 1.x cannot be upgraded past a > > > > certain point. These include, but not limited to, versions of > > > > software beyond Java 11, Jetty > > > 9, > > > > Spring 5 and AngularJS 1.8. For the most inclusive and continuing > > > support > > > > from the Apache NiFi team, we strongly encourage users to migrate to > > > > NiFi 2.0" > > > > > > > > -- other Mike > > > > > > > > > > > > On Thu, Nov 7, 2024 at 3:07 PM Mike Thomsen <mikerthom...@gmail.com> > > > wrote: > > > > > > > > > Joe, > > > > > > > > > > I would modify the End of Life/End of Support to be End of New > > > Development. > > > > > From what I've seen over the years, End of Life/End of Support is > > > typically > > > > > used by vendors to imply a hard cut off date for free support. The > > > > > way > > > I > > > > > take your proposal is that it's a message that new development and > > > > > bug fixes will head to 2.X, but the community will get reasonable > > > > > security support for a while, provided volunteers can be found to > > > > > help out. It's that connotation of "hard stop" with End of Lie > > > > > that I think warrants something like End of Active Development. > > > > > > > > > > At the end of the day, perhaps I'm overthinking this, but when I > > > > > hear > > > "End > > > > > of Life," that's where my mind goes immediately. I think most > > > > > people > > > would > > > > > immediately think that 1.28.1 is it, and if they can't get onto > > > > > 2.X in > > > a > > > > > reasonable time, they might be taking on personal risk if an issue > > > > > like log4shell comes up, and their leadership finds out that they > > > > > have an unclear (to them) support path. It is technically clear > > > > > (go to 2.X) but with any big effort with a lot of stakeholders, > > > > > that might not be immediately viable, and I could see it quickly > > > > > turn into a semantical > > > fight > > > > > over the meaning of "End of Life" for people trying to support 1.X > > > > > and > > > make > > > > > the case for 2.X in that environment. > > > > > > > > > > > > > > > On Thu, Nov 7, 2024 at 12:10 PM Joe Witt <joe.w...@gmail.com> wrote: > > > > > > > > > > > Mike, > > > > > > > > > > > > To your first paragraph then I interpret that to read the same > > > > > > as my proposal intended to read. Can you please provide > > > > > > specific wording > > > > > changes > > > > > > in the event your proposal differs. > > > > > > > > > > > > To your second paragraph those things are prudent generally and > > > there is > > > > > > nothing new that would require that guidance at this time. > > > > > > > > > > > > Thanks > > > > > > > > > > > > I wrote: > > > > > > 1. Declare the NiFi 1.28.x line as the 'End of Life/End of Support' > > > line. > > > > > > This means we may still do periodic bug fixes or when > > > possible/reasonable > > > > > > bump vulnerable libs. But we will not be doing further > > > analysis/triage > > > > > of > > > > > > security reports nor adding features. > > > > > > > > > > > > 2. Add a DISCLAIMER to the source and key binaries of the > > > > > > 1.x/1.28 > > > line > > > > > > [1]. > > > > > > > > > > > > 3. Update the downloads page making the links for nifi source > > > > > > and the > > > > > main > > > > > > nifi assembly of whatever is the latest NiFi 1.28.x release > > > > > > there but clearly articulated as the end of support line for > > > > > > which bug fixes > > > and > > > > > some > > > > > > narrow dependency updates may occur. Advise users of the 1.x > > > > > > line > > > of the > > > > > > importance of planning to migrate to the 2.x line. > > > > > > > > > > > > 4. Conduct a VOTE to codify this. > > > > > > > > > > > > 5. Conduct an Apache NiFi 1.28.1 release to pickle up (2) and > > > > > > the bug > > > > > fixes > > > > > > already available. > > > > > > > > > > > > 6. As we gather more user input on things which are helpful to > > > > > > them > > > we > > > > > > factor these into migration guidance/tooling as appropriate on > > > > > > the > > > 2.x > > > > > > line. > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Nov 7, 2024 at 10:03 AM Mike Thomsen > > > > > > <mikerthom...@gmail.com > > > > > > > > > > wrote: > > > > > > > > > > > > > Alright. > > > > > > > > > > > > > > I would suggest we go with the basic concept of EOL sometime > > > > > > > this > > > year, > > > > > > but > > > > > > > phrase it more gently as End of Active Development with a > > > > > > > focus on > > > > > 1.28.1 > > > > > > > and beyond being "transition support snapshots for NiFi 1.X." > > > > > > > What > > > we > > > > > > want > > > > > > > to convey is "we hear you, you need time, we'll try to help > > > > > > > smooth > > > this > > > > > > > over where we can" to enterprise users. I think a commitment > > > > > > > to at > > > > > least > > > > > > > trying to patch CVEs where possible for up to a year, provided > > > there > > > > > are > > > > > > > volunteers, would be reasonable for us as an offer to meet > > > > > > > users > > > > > halfway. > > > > > > > > > > > > > > My guidance as an integrator to our security team would be to > > > > > > > begin transitioning any instances that are public facing to be > > > > > > > behind a > > > VPN > > > > > by > > > > > > > the end of 2025 Q1, as that will effectively mitigate a lot of > > > > > > > the > > > > > > concerns > > > > > > > raised up thread about Internet-related dangers to active NiFi > > > > > > instances. I > > > > > > > would also recommend that any systems that touch the API begin > > > > > evaluating > > > > > > > application-specific firewall rules and AWS security groups to > > > ensure > > > > > > that > > > > > > > NiFi's REST APIs are accessible only to other applications > > > > > > > that > > > have > > > > > been > > > > > > > whitelisted. > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Thu, Nov 7, 2024 at 11:18 AM Joe Witt <joe.w...@gmail.com> > > > wrote: > > > > > > > > > > > > > > > Mike > > > > > > > > > > > > > > > > I hear you. > > > > > > > > > > > > > > > > As a PMC member please make a concrete proposal and offer > > > > > > > > wording > > > > > that > > > > > > > you > > > > > > > > think helps the community conduct its mission and the users > > > benefit > > > > > > from > > > > > > > > it. > > > > > > > > > > > > > > > > Thanks > > > > > > > > Joe > > > > > > > > > > > > > > > > On Thu, Nov 7, 2024 at 9:12 AM Mike Thomsen < > > > mikerthom...@gmail.com> > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > it is always connected to external systems, and mostly > > > exposed to > > > > > > the > > > > > > > > > Internet by connecting to many systems. > > > > > > > > > > > > > > > > > > Depending on what you mean by this, I think this could be > > > > > > > > > a > > > very > > > > > bad > > > > > > > > thing > > > > > > > > > for a company akin to exposing something like Kibana > > > > > > > > > without > > > going > > > > > > > > through > > > > > > > > > a VPN. > > > > > > > > > > > > > > > > > > On Tue, Nov 5, 2024 at 3:00 PM ski n > > > > > > > > > <raymondmees...@gmail.com > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > I think this is a good proposal. > > > > > > > > > > > > > > > > > > > > I would also like to share my experience as an > > > > > > > > > > integration > > > > > > consultant > > > > > > > > > > implementing various integration systems for large > > > enterprises. > > > > > > > > > > > > > > > > > > > > In general, these organizations are very conservative. > > > > > > > > > > The > > > > > > milestone > > > > > > > > > > releases (like those for 2.0) are completely ignored. It > > > doesn't > > > > > > > matter > > > > > > > > > if > > > > > > > > > > they are already running in production in other > > > organizations. > > > > > The > > > > > > > > first > > > > > > > > > GA > > > > > > > > > > release of a new major release isn't trusted either. > > > > > > > > > > Only > > > after a > > > > > > > > couple > > > > > > > > > of > > > > > > > > > > minor releases and when there is a new long-term support > > > release, > > > > > > > they > > > > > > > > > > start to think. > > > > > > > > > > > > > > > > > > > > Upgrading often disrupts day-to-day operations, business > > > > > > > requirements, > > > > > > > > > and > > > > > > > > > > consumes resources. Only when an LTS arrives, the > > > > > > > > > > pressure > > > from > > > > > the > > > > > > > > > > security/dev team is high enough, the project budget is > > > > > available, > > > > > > it > > > > > > > > > fits > > > > > > > > > > into the company roadmap, and so on... does a > > > migration/upgrade > > > > > > > begin. > > > > > > > > > With > > > > > > > > > > thousands of flows and daily operations, all the > > > > > > > > > > migration > > > and > > > > > > > > retesting > > > > > > > > > > can take a long time. > > > > > > > > > > > > > > > > > > > > I think most organizations expect that version 1.x will > > > > > > > > > > be > > > > > > supported > > > > > > > > for > > > > > > > > > > many years, next to the new major that has just arrived. > > > > > > > > > > I'm > > > not > > > > > > > saying > > > > > > > > > > it's good, or possible, or safe, etc., but those are > > > > > > > > > > just the > > > > > > > timelines > > > > > > > > > and > > > > > > > > > > expectations in large organizations. Companies like > > > Microsoft and > > > > > > > > Oracle > > > > > > > > > > understand this very well. They often offer (and charge > > > > > > > > > > for) > > > very > > > > > > > long > > > > > > > > > > timelines for their operating systems and software. > > > > > > > > > > > > > > > > > > > > An open source project relies mostly on other open > > > > > > > > > > source > > > > > projects. > > > > > > > > These > > > > > > > > > > may or may not have an EOL. The problem on top of this > > > > > > > > > > with > > > > > > > integration > > > > > > > > > > software like NiFi is that, by its nature, it is always > > > connected > > > > > > to > > > > > > > > > > external systems, and mostly exposed to the Internet by > > > > > connecting > > > > > > to > > > > > > > > > many > > > > > > > > > > systems. > > > > > > > > > > > > > > > > > > > > Thus make it very clear what the risks are, but still > > > > > > > > > > offer > > > bug > > > > > > fixes > > > > > > > > for > > > > > > > > > > some time, is probably the best way forward. > > > > > > > > > > > > > > > > > > > > Raymond > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Nov 5, 2024 at 8:31 PM Joe Witt > > > > > > > > > > <joe.w...@gmail.com> > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > To be actionable and concrete here is a proposal: > > > > > > > > > > > > > > > > > > > > > > 1. Declare the NiFi 1.28.x line as the 'End of > > > > > > > > > > > Life/End of > > > > > > Support' > > > > > > > > > line. > > > > > > > > > > > This means we may still do periodic bug fixes or when > > > > > > > > > possible/reasonable > > > > > > > > > > > bump vulnerable libs. But we will not be doing > > > > > > > > > > > further > > > > > > > > analysis/triage > > > > > > > > > > of > > > > > > > > > > > security reports nor adding features. > > > > > > > > > > > > > > > > > > > > > > 2. Add a DISCLAIMER to the source and key binaries of > > > > > > > > > > > the > > > > > > 1.x/1.28 > > > > > > > > line > > > > > > > > > > > [1]. > > > > > > > > > > > > > > > > > > > > > > 3. Update the downloads page making the links for nifi > > > source > > > > > and > > > > > > > the > > > > > > > > > > main > > > > > > > > > > > nifi assembly of whatever is the latest NiFi 1.28.x > > > > > > > > > > > release > > > > > there > > > > > > > but > > > > > > > > > > > clearly articulated as the end of support line for > > > > > > > > > > > which > > > bug > > > > > > fixes > > > > > > > > and > > > > > > > > > > some > > > > > > > > > > > narrow dependency updates may occur. Advise users of > > > > > > > > > > > the > > > 1.x > > > > > > line > > > > > > > of > > > > > > > > > the > > > > > > > > > > > importance of planning to migrate to the 2.x line. > > > > > > > > > > > > > > > > > > > > > > 4. Conduct a VOTE to codify this. > > > > > > > > > > > > > > > > > > > > > > 5. Conduct an Apache NiFi 1.28.1 release to pickle up > > > > > > > > > > > (2) > > > and > > > > > the > > > > > > > bug > > > > > > > > > > fixes > > > > > > > > > > > already available. > > > > > > > > > > > > > > > > > > > > > > 6. As we gather more user input on things which are > > > helpful to > > > > > > them > > > > > > > > we > > > > > > > > > > > factor these into migration guidance/tooling as > > > appropriate on > > > > > > the > > > > > > > > 2.x > > > > > > > > > > > line. > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > https://eur03.safelinks.protection.outlook.com/?url=ht > > > > > > > > > > > tps%3A%2F%2Fgithub.com%2Fapache%2Fnifi%2Fpull%2F9491&d > > > > > > > > > > > ata=05%7C02%7Cisha.lamboo%40virtualsciences.nl%7Cf08b0 > > > > > > > > > > > efbd80149d3cbd508dcff6d6c0f%7C21429da9e4ad45f99a6fcd12 > > > > > > > > > > > 6a64274b%7C0%7C0%7C638666092667241553%7CUnknown%7CTWFp > > > > > > > > > > > bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik > > > > > > > > > > > 1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=Wp2thWionlzpD5 > > > > > > > > > > > syVAEAFc07e33b8uhOE%2FlXj%2F5xNMk%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > > > On Tue, Nov 5, 2024 at 9:04 AM Joe Witt < > > > joe.w...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > Team, > > > > > > > > > > > > > > > > > > > > > > > > I will start a discussion thread on the users list > > > > > > > > > > > > so we > > > can > > > > > > hear > > > > > > > > > more > > > > > > > > > > > > inputs from them and from that perspective. > > > > > > > > > > > > > > > > > > > > > > > > This thread needs to focus on what the > > > > > > > contributors/committers/PMC > > > > > > > > in > > > > > > > > > > the > > > > > > > > > > > > community can/will/should do and the PMC in > > > > > > > > > > > > particular as > > > > > we're > > > > > > > > > > obligated > > > > > > > > > > > > to ensure we're putting out software for which we > > > > > > > > > > > > can > > > stand > > > > > > > behind > > > > > > > > > its > > > > > > > > > > > > security posture. > > > > > > > > > > > > > > > > > > > > > > > > We do not need to get worried about customers. They > > > > > > > > > > > > have > > > > > > vendors > > > > > > > > > that > > > > > > > > > > > > support them. What we need to worry about and > > > > > > > > > > > > continue > > > to do > > > > > > an > > > > > > > > > > > excellent > > > > > > > > > > > > job caring for is the apache nifi user base and we > > > > > > > > > > > > need > > > to > > > > > > ensure > > > > > > > > > they > > > > > > > > > > > > don't have the belief that the NiFi 1.x line will be > > > fixed in > > > > > > the > > > > > > > > > > > presence > > > > > > > > > > > > of vulnerability reports. I'll ask on the users > > > > > > > > > > > > list how > > > > > folks > > > > > > > > would > > > > > > > > > > > like > > > > > > > > > > > > us to communicate about the state of things. > > > > > > > > > > > > > > > > > > > > > > > > What I think we need to ask here is more in the > > > > > > > > > > > > spirit of > > > > > what > > > > > > > this > > > > > > > > > > > thread > > > > > > > > > > > > was started about. When do we as a > > > contributor/committer/PMC > > > > > > > base > > > > > > > > > want > > > > > > > > > > > to > > > > > > > > > > > > make it official in our own sense that we will not > > > > > > > > > > > > be > > > > > producing > > > > > > > > > > releases > > > > > > > > > > > > for the 1.x line? How we best communicate/help the > > > > > > > > > > > > user > > > base > > > > > > > then > > > > > > > > > > > follows > > > > > > > > > > > > from that. Stated another way those who feel they > > > > > > > > > > > > will > > > be > > > > > in a > > > > > > > > good > > > > > > > > > > > > position to do security reviews, vulnerability scans > > > > > > > > > > > > and > > > > > > > > remediation, > > > > > > > > > > > > conduct releases for some period of time please > > > > > > > > > > > > share > > > what > > > > > you > > > > > > > > think > > > > > > > > > > > you'll > > > > > > > > > > > > be able to do and roughly for how long. > > > > > > > > > > > > > > > > > > > > > > > > Thanks > > > > > > > > > > > > > > > > > > > > > > > > On Tue, Nov 5, 2024 at 3:36 AM Pierre Villard < > > > > > > > > > > > pierre.villard...@gmail.com> > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > >> Hi all, > > > > > > > > > > > >> > > > > > > > > > > > >> While I think we could set an EOL date a bit > > > > > > > > > > > >> further in > > > the > > > > > > > > future, > > > > > > > > > it > > > > > > > > > > > is > > > > > > > > > > > >> important to keep in mind what EOL means. It only > > > > > > > > > > > >> means > > > we > > > > > > won't > > > > > > > > be > > > > > > > > > > > >> providing security fixes / bug fixes through new > > > releases. > > > > > It > > > > > > > does > > > > > > > > > not > > > > > > > > > > > >> mean that NiFi 1.x is gone. If that is a big > > > > > > > > > > > >> concern for > > > > > some > > > > > > > > users > > > > > > > > > > when > > > > > > > > > > > >> running EOL software then we should remind those > > > > > > > > > > > >> users > > > that > > > > > > > > they've > > > > > > > > > > been > > > > > > > > > > > >> doing it for 2+ years already when using NiFi 1.x > > > (taking > > > > > > Jetty > > > > > > > as > > > > > > > > > an > > > > > > > > > > > >> example here). And Joe is definitely right when > > > > > > > > > > > >> saying > > > that > > > > > we > > > > > > > > have > > > > > > > > > a > > > > > > > > > > > >> smaller and smaller group of people willing to > > > > > > > > > > > >> spend an > > > > > > > extensive > > > > > > > > > > amount > > > > > > > > > > > >> of > > > > > > > > > > > >> time taking care of PR/reviews, of release > > > > > > > > > > > >> candidates, > > > > > > > > > > > testing/validating > > > > > > > > > > > >> RCs, etc, for the 1.x line. > > > > > > > > > > > >> > > > > > > > > > > > >> I also agree that, even if many users are already > > > > > > > > > > > >> using > > > > > NiFi 2 > > > > > > > in > > > > > > > > > > > >> production, many places have strict policies to not > > > adopt a > > > > > > new > > > > > > > > > major > > > > > > > > > > > >> release. I don't want to start a debate whether > > > > > > > > > > > >> this is > > > > > making > > > > > > > > sense > > > > > > > > > > or > > > > > > > > > > > >> not > > > > > > > > > > > >> but we know those rules exist in many places :) And > > > > > > > > > > > >> the > > > fact > > > > > > > that > > > > > > > > we > > > > > > > > > > had > > > > > > > > > > > >> milestone releases for one year is not going to be > > > enough of > > > > > > an > > > > > > > > > > > argument. > > > > > > > > > > > >> > > > > > > > > > > > >> Given what we've seen in the past, we usually make > > > > > > > > > > > >> a new > > > > > > release > > > > > > > > > > every 3 > > > > > > > > > > > >> months or so. It's probably fair to assume a 2.1.0 > > > release > > > > > > will > > > > > > > > > happen > > > > > > > > > > > >> early next year. With that in mind, I tend to agree > > > > > > > > > > > >> with > > > > > > Michael > > > > > > > > > > > >> suggesting > > > > > > > > > > > >> an EOL date at the end of January (3 months from now). > > > We > > > > > > could > > > > > > > > also > > > > > > > > > > say > > > > > > > > > > > >> that 1.28.1 will happen at this time and will be > > > > > > > > > > > >> the > > > last > > > > > one > > > > > > in > > > > > > > > the > > > > > > > > > > > >> community. > > > > > > > > > > > >> > > > > > > > > > > > >> Vendors have already announced support for NiFi 1.x > > > > > > > > > > > >> for > > > > > > multiple > > > > > > > > > > > >> additional > > > > > > > > > > > >> years so this approach follows what we see in other > > > projects > > > > > > > where > > > > > > > > > > > >> extended > > > > > > > > > > > >> support is only provided through paid options with > > > specific > > > > > > > > > companies. > > > > > > > > > > > >> > > > > > > > > > > > >> It is awesome to finally see 2.0 out and this > > > > > > > > > > > >> decision > > > will > > > > > > help > > > > > > > > > drive > > > > > > > > > > > >> users to that new release, which is much better in > > > > > > > > > > > >> so > > > many > > > > > > > ways... > > > > > > > > > > > >> > > > > > > > > > > > >> Thanks, > > > > > > > > > > > >> Pierre > > > > > > > > > > > >> > > > > > > > > > > > >> > > > > > > > > > > > >> Le mar. 5 nov. 2024 à 10:36, Isha Lamboo < > > > > > > > > > > > isha.lam...@virtualsciences.nl> > > > > > > > > > > > >> a > > > > > > > > > > > >> écrit : > > > > > > > > > > > >> > > > > > > > > > > > >> > 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: > > > > > > > > > > > >> > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
