Re: [discuss] NiFi 1.20 and NiFi 2.0
Hi David, Thanks for the reply. I appreciate it, no further questions from me. David wrote: > For deployments that are not using deprecated components and > features in 1.x... That's going to be a hard one to sort out, as historically large NiFi deployments are likely going to have at least some usage of deprecated components in active production. And rolling out a "major" version change will take quite a long time for these folks to get right. If the 2.0 train moves ahead too quickly, and the 1.x releases stop and/or are abandoned shortly afterwards, these types of "legacy" deployments are going to suffer and will feel left behind. That's usually when communities / projects get forked. My timing/calendar questions are as much about understanding the 1.x support lifecycle and keeping these slow movers alive than anything. It would be bad if the rush to 2.0 comes at the expense of existing deployments. Again, thanks for the thorough reply. /Adam On Mon, Jan 9, 2023 at 6:52 PM David Handermann wrote: > Adam, > > Thanks for the reply. > > To clarify my statement about traction on 2.0 release goals, I stated it > that way because I would like to see some measurable progress on the 2.0 > release goals before attempting to put forward any kind of timeline for > release. I didn't mean to imply an increase in instability in the main > branch, and that is not what I had in mind. On the contrary, the main > branch should continue to be considered stable and current, and we should > continue to apply the same level of rigor for all commits to the main > branch. Changing major versions should not alter that approach. > > As outlined in the 2.0 Release Goals [1] the majority of the changes > involve removal of deprecated components and features, as opposed to adding > new and unstable capabilities. From that angle, a 2.0 major release should > be stable, and the only concern should be that we are surgical in the > removal process. That strategy is a large part of the reason that moving > the main branch to 2.0.0-SNAPSHOT should not be seen as extremely > disruptive. For deployments that are not using deprecated components and > features in 1.x, upgrading to 2.x should be similar to upgrading between > minor release versions. > > I appreciate the concern about potential disruption, and concern about > stability. These concerns are important to keep in mind as we move forward. > As long as we follow this approach, we should be able to maintain the level > of stability that the community rightly expects. > > Regards, > David Handermann > > [1] > https://cwiki.apache.org/confluence/display/NIFI/NiFi+2.0+Release+Goals > > > > On Mon, Jan 9, 2023 at 6:08 PM Adam Taft wrote: > > > I think this sentence is capturing some of my question ... > > > > David wrote: > > > I think it would be helpful to see some traction on the 2.0 release > goals > > > before attempting to sketch out a potential timeline. > > > > It feels like what you're saying is that the "main" git branch is going > to > > become an alpha or beta for the 2.0.0 release, and that the newly > proposed > > "1.x" branch will be the stable branch. Without any existing traction on > > the 2.0 release goals (as you've stated), it would start to feel that the > > main branch doesn't maintain a predictable stability. Folks would have to > > be looking at the 1.x branch for stable releases for an undefined period > of > > time. > > > > This is contrary to most philosophies as to what the "main" branch should > > imply. Typically, the "alpha/beta" work for a major upcoming revision > would > > occur in a separate off-main branch until there is at least some fidelity > > with the release goals. And then switching main from the 1.x to 2.x code > > base would ideally happen as late as possible in the 2.0.0 release > > candidate timeframe. > > > > It's splitting hairs, of course. Branches are just branches. But I do > think > > it's smart to keep the main branch tracking what is considered the > > currently stable release, not a future beta. I can foresee that there > will > > be many 2.0.0 release candidates and late-adopter reluctance to jump onto > > the 2.0 release until a few cycles of stability have been demonstrated. > I'd > > rather feel like we can recommend a 2.0 release straight out of the gate > > rather than waiting for it to stabilize. > > > > No big deal here. Just trying to anticipate what to communicate to people > > once main switches over. It sounds like the communication will be, > "ignore > > the main branch, and focus on the 1.x branch, if you want to be > > conservative." > > > > /Adam > > > > > > > > > > On Mon, Jan 9, 2023 at 3:24 PM David Handermann < > > exceptionfact...@apache.org> > > wrote: > > > > > Joe, > > > > > > Thanks for keeping things moving forward in terms of a 1.20 release and > > 2.0 > > > branching plan. Releasing 1.20 and moving the main branch to > > 2.0.0-SNAPSHOT > > > aligns with the approved goals and provides a
Re: [discuss] NiFi 1.20 and NiFi 2.0
Adam, Thanks for the reply. To clarify my statement about traction on 2.0 release goals, I stated it that way because I would like to see some measurable progress on the 2.0 release goals before attempting to put forward any kind of timeline for release. I didn't mean to imply an increase in instability in the main branch, and that is not what I had in mind. On the contrary, the main branch should continue to be considered stable and current, and we should continue to apply the same level of rigor for all commits to the main branch. Changing major versions should not alter that approach. As outlined in the 2.0 Release Goals [1] the majority of the changes involve removal of deprecated components and features, as opposed to adding new and unstable capabilities. From that angle, a 2.0 major release should be stable, and the only concern should be that we are surgical in the removal process. That strategy is a large part of the reason that moving the main branch to 2.0.0-SNAPSHOT should not be seen as extremely disruptive. For deployments that are not using deprecated components and features in 1.x, upgrading to 2.x should be similar to upgrading between minor release versions. I appreciate the concern about potential disruption, and concern about stability. These concerns are important to keep in mind as we move forward. As long as we follow this approach, we should be able to maintain the level of stability that the community rightly expects. Regards, David Handermann [1] https://cwiki.apache.org/confluence/display/NIFI/NiFi+2.0+Release+Goals On Mon, Jan 9, 2023 at 6:08 PM Adam Taft wrote: > I think this sentence is capturing some of my question ... > > David wrote: > > I think it would be helpful to see some traction on the 2.0 release goals > > before attempting to sketch out a potential timeline. > > It feels like what you're saying is that the "main" git branch is going to > become an alpha or beta for the 2.0.0 release, and that the newly proposed > "1.x" branch will be the stable branch. Without any existing traction on > the 2.0 release goals (as you've stated), it would start to feel that the > main branch doesn't maintain a predictable stability. Folks would have to > be looking at the 1.x branch for stable releases for an undefined period of > time. > > This is contrary to most philosophies as to what the "main" branch should > imply. Typically, the "alpha/beta" work for a major upcoming revision would > occur in a separate off-main branch until there is at least some fidelity > with the release goals. And then switching main from the 1.x to 2.x code > base would ideally happen as late as possible in the 2.0.0 release > candidate timeframe. > > It's splitting hairs, of course. Branches are just branches. But I do think > it's smart to keep the main branch tracking what is considered the > currently stable release, not a future beta. I can foresee that there will > be many 2.0.0 release candidates and late-adopter reluctance to jump onto > the 2.0 release until a few cycles of stability have been demonstrated. I'd > rather feel like we can recommend a 2.0 release straight out of the gate > rather than waiting for it to stabilize. > > No big deal here. Just trying to anticipate what to communicate to people > once main switches over. It sounds like the communication will be, "ignore > the main branch, and focus on the 1.x branch, if you want to be > conservative." > > /Adam > > > > > On Mon, Jan 9, 2023 at 3:24 PM David Handermann < > exceptionfact...@apache.org> > wrote: > > > Joe, > > > > Thanks for keeping things moving forward in terms of a 1.20 release and > 2.0 > > branching plan. Releasing 1.20 and moving the main branch to > 2.0.0-SNAPSHOT > > aligns with the approved goals and provides a natural breakpoint for > > continued development on both branches. > > > > Adam, > > > > Thanks for raising the questions about timeline, I'm sure others have > > similar questions. I think it is probably a little too early to propose > > general timelines, but on the other hand, I think the historical pace of > > releases should be a good indication of continued release cadence. > > > > The 2.0 Release Goals did not include a timeline for the major release, > or > > subsequent minor releases, by design, but these are certainly questions > we > > should answer. > > > > We know that we will need at least one or 1.x releases to complete > > additional migration preparation work. With the scope of 2.0 Release > Goals > > purposefully limited, I would not expect extensive delays. We may need to > > have a longer release candidate period, or more incremental fix releases > > for the initial 2.0.0 release train, but I do not expect delaying a 2.0.0 > > release for new features, as that is not part of the release goals. > > > > I think it would be helpful to see some traction on the 2.0 release goals > > before attempting to sketch out a potential timeline. > > > > Regards, > > David Handermann > > > >
Re: [discuss] NiFi 1.20 and NiFi 2.0
I think this sentence is capturing some of my question ... David wrote: > I think it would be helpful to see some traction on the 2.0 release goals > before attempting to sketch out a potential timeline. It feels like what you're saying is that the "main" git branch is going to become an alpha or beta for the 2.0.0 release, and that the newly proposed "1.x" branch will be the stable branch. Without any existing traction on the 2.0 release goals (as you've stated), it would start to feel that the main branch doesn't maintain a predictable stability. Folks would have to be looking at the 1.x branch for stable releases for an undefined period of time. This is contrary to most philosophies as to what the "main" branch should imply. Typically, the "alpha/beta" work for a major upcoming revision would occur in a separate off-main branch until there is at least some fidelity with the release goals. And then switching main from the 1.x to 2.x code base would ideally happen as late as possible in the 2.0.0 release candidate timeframe. It's splitting hairs, of course. Branches are just branches. But I do think it's smart to keep the main branch tracking what is considered the currently stable release, not a future beta. I can foresee that there will be many 2.0.0 release candidates and late-adopter reluctance to jump onto the 2.0 release until a few cycles of stability have been demonstrated. I'd rather feel like we can recommend a 2.0 release straight out of the gate rather than waiting for it to stabilize. No big deal here. Just trying to anticipate what to communicate to people once main switches over. It sounds like the communication will be, "ignore the main branch, and focus on the 1.x branch, if you want to be conservative." /Adam On Mon, Jan 9, 2023 at 3:24 PM David Handermann wrote: > Joe, > > Thanks for keeping things moving forward in terms of a 1.20 release and 2.0 > branching plan. Releasing 1.20 and moving the main branch to 2.0.0-SNAPSHOT > aligns with the approved goals and provides a natural breakpoint for > continued development on both branches. > > Adam, > > Thanks for raising the questions about timeline, I'm sure others have > similar questions. I think it is probably a little too early to propose > general timelines, but on the other hand, I think the historical pace of > releases should be a good indication of continued release cadence. > > The 2.0 Release Goals did not include a timeline for the major release, or > subsequent minor releases, by design, but these are certainly questions we > should answer. > > We know that we will need at least one or 1.x releases to complete > additional migration preparation work. With the scope of 2.0 Release Goals > purposefully limited, I would not expect extensive delays. We may need to > have a longer release candidate period, or more incremental fix releases > for the initial 2.0.0 release train, but I do not expect delaying a 2.0.0 > release for new features, as that is not part of the release goals. > > I think it would be helpful to see some traction on the 2.0 release goals > before attempting to sketch out a potential timeline. > > Regards, > David Handermann > > On Mon, Jan 9, 2023 at 3:50 PM Adam Taft wrote: > > > Joe / team, > > > > Question on this. I think it would be helpful to understand the desired > > timelines for the first 2.0.0 release. I know it's not strictly > > predictable, but having a sense of what the timing looks like is > important > > to help understand the implications of a "maintenance only" 1.x line. The > > schedule would ideally come from the folks who are actively looking at / > > contributing to the 2.0 release. They probably have the best gauge as to > > "when" it might happen (under ideal conditions). > > > > One of the risks, of course, is if the 2.0 release stalls or delays. > Having > > an idea of how 1.x might evolve for the users who are not necessarily > > early-adopters or those that need longer support tails. If 2.0 is delayed > > and 1.x looks unmaintained, there's a potential chance for the project to > > lose a bit of credibility. I know we don't anticipate this scenario, but > if > > we had a plan for it, that would be reassuring. > > > > Maybe this was already addressed, I apologize if so. But if not, can we > > throw some darts on the calendar to help understand the ideal rollout of > > 2.0 on a timeline? And are there any adjustments for the scenario > described > > above? > > > > Thanks in advance, > > > > /Adam > > > > > > On Mon, Jan 9, 2023 at 1:53 PM Joe Witt wrote: > > > > > Team, > > > > > > As David mentioned in [1] following a successful NiFi 2.0 release goal > > > planning - we are now going to start moving the 'main' line to be the > > NiFi > > > 2.0 line which will allow for the key work to take place. We will also > > > move niFi 1.x to its appropriate support line. > > > > > > It is also the case that we have nearly 100 JIRAs on NiFi 1.20 and we > > have > > > work in
Question About Documentation
Hello, I asked this question in the slack channel too. Feel free to answer in either spot. I just wanted to give multiple options. Slack spot: https://apachenifi.slack.com/archives/C0L9VCD47/p1673302349887899 My question: I am using an older NiFi version and was trying to find documentation for it but when going to https://nifi.apache.org/docs.html, it only shows the latest. I cannot find a button or a way to look at older documentation. Is there a way? Thank you for your time. Best, Paul Anzalone paul.anzal...@caci.com This electronic message contains information from CACI International Inc or subsidiary companies, which may be company sensitive, proprietary, privileged or otherwise protected from disclosure. The information is intended to be used solely by the recipient(s) named above. If you are not an intended recipient, be aware that any review, disclosure, copying, distribution or use of this transmission or its contents is prohibited. If you have received this transmission in error, please notify the sender immediately.
Re: [discuss] NiFi 1.20 and NiFi 2.0
Joe, Thanks for keeping things moving forward in terms of a 1.20 release and 2.0 branching plan. Releasing 1.20 and moving the main branch to 2.0.0-SNAPSHOT aligns with the approved goals and provides a natural breakpoint for continued development on both branches. Adam, Thanks for raising the questions about timeline, I'm sure others have similar questions. I think it is probably a little too early to propose general timelines, but on the other hand, I think the historical pace of releases should be a good indication of continued release cadence. The 2.0 Release Goals did not include a timeline for the major release, or subsequent minor releases, by design, but these are certainly questions we should answer. We know that we will need at least one or 1.x releases to complete additional migration preparation work. With the scope of 2.0 Release Goals purposefully limited, I would not expect extensive delays. We may need to have a longer release candidate period, or more incremental fix releases for the initial 2.0.0 release train, but I do not expect delaying a 2.0.0 release for new features, as that is not part of the release goals. I think it would be helpful to see some traction on the 2.0 release goals before attempting to sketch out a potential timeline. Regards, David Handermann On Mon, Jan 9, 2023 at 3:50 PM Adam Taft wrote: > Joe / team, > > Question on this. I think it would be helpful to understand the desired > timelines for the first 2.0.0 release. I know it's not strictly > predictable, but having a sense of what the timing looks like is important > to help understand the implications of a "maintenance only" 1.x line. The > schedule would ideally come from the folks who are actively looking at / > contributing to the 2.0 release. They probably have the best gauge as to > "when" it might happen (under ideal conditions). > > One of the risks, of course, is if the 2.0 release stalls or delays. Having > an idea of how 1.x might evolve for the users who are not necessarily > early-adopters or those that need longer support tails. If 2.0 is delayed > and 1.x looks unmaintained, there's a potential chance for the project to > lose a bit of credibility. I know we don't anticipate this scenario, but if > we had a plan for it, that would be reassuring. > > Maybe this was already addressed, I apologize if so. But if not, can we > throw some darts on the calendar to help understand the ideal rollout of > 2.0 on a timeline? And are there any adjustments for the scenario described > above? > > Thanks in advance, > > /Adam > > > On Mon, Jan 9, 2023 at 1:53 PM Joe Witt wrote: > > > Team, > > > > As David mentioned in [1] following a successful NiFi 2.0 release goal > > planning - we are now going to start moving the 'main' line to be the > NiFi > > 2.0 line which will allow for the key work to take place. We will also > > move niFi 1.x to its appropriate support line. > > > > It is also the case that we have nearly 100 JIRAs on NiFi 1.20 and we > have > > work in there including security items so it is time to make a release. > > The intent then is to initiate 1.20 and immediate after that change > 'main' > > to 2.0. > > > > Going forward then all work on the 1.x line should be focused on > > maintaining existing features, dependencies, and helping 1.x users > migrate > > to the 2.x line. Otherwise, new feature work will happen on 'main' as it > > normally does and will come out in the NiFi 2.x release line. > > > > Please flag key outstanding items as we narrow down the release candidate > > for NiFi 1.20. > > > > Thanks > > Joe > > > > [1] https://lists.apache.org/thread/qo4vvdw46235y7vy2crcd6l4m11wl7jz > > >
Re: [discuss] NiFi 1.20 and NiFi 2.0
Hi Joe, Sorry if this is a dumb question, but is there some documentation around what 2.0 might mean? My personal interest is in backwards compatibility of existing custom processors. Thanks, Phil On Tue, 10 Jan 2023 at 06:53, Joe Witt wrote: > Team, > > As David mentioned in [1] following a successful NiFi 2.0 release goal > planning - we are now going to start moving the 'main' line to be the NiFi > 2.0 line which will allow for the key work to take place. We will also > move niFi 1.x to its appropriate support line. > > It is also the case that we have nearly 100 JIRAs on NiFi 1.20 and we have > work in there including security items so it is time to make a release. > The intent then is to initiate 1.20 and immediate after that change 'main' > to 2.0. > > Going forward then all work on the 1.x line should be focused on > maintaining existing features, dependencies, and helping 1.x users migrate > to the 2.x line. Otherwise, new feature work will happen on 'main' as it > normally does and will come out in the NiFi 2.x release line. > > Please flag key outstanding items as we narrow down the release candidate > for NiFi 1.20. > > Thanks > Joe > > [1] https://lists.apache.org/thread/qo4vvdw46235y7vy2crcd6l4m11wl7jz >
Re: [discuss] NiFi 1.20 and NiFi 2.0
I second some calendar guessing. There's been releases every 1-2 months for a while now. I'd be curious what a guess at a gap would be between 1.20.0 and a GA of 2.0.0. Thanks, Ryan On Mon, Jan 9, 2023 at 4:50 PM Adam Taft wrote: > Joe / team, > > Question on this. I think it would be helpful to understand the desired > timelines for the first 2.0.0 release. I know it's not strictly > predictable, but having a sense of what the timing looks like is important > to help understand the implications of a "maintenance only" 1.x line. The > schedule would ideally come from the folks who are actively looking at / > contributing to the 2.0 release. They probably have the best gauge as to > "when" it might happen (under ideal conditions). > > One of the risks, of course, is if the 2.0 release stalls or delays. Having > an idea of how 1.x might evolve for the users who are not necessarily > early-adopters or those that need longer support tails. If 2.0 is delayed > and 1.x looks unmaintained, there's a potential chance for the project to > lose a bit of credibility. I know we don't anticipate this scenario, but if > we had a plan for it, that would be reassuring. > > Maybe this was already addressed, I apologize if so. But if not, can we > throw some darts on the calendar to help understand the ideal rollout of > 2.0 on a timeline? And are there any adjustments for the scenario described > above? > > Thanks in advance, > > /Adam > > > On Mon, Jan 9, 2023 at 1:53 PM Joe Witt wrote: > > > Team, > > > > As David mentioned in [1] following a successful NiFi 2.0 release goal > > planning - we are now going to start moving the 'main' line to be the > NiFi > > 2.0 line which will allow for the key work to take place. We will also > > move niFi 1.x to its appropriate support line. > > > > It is also the case that we have nearly 100 JIRAs on NiFi 1.20 and we > have > > work in there including security items so it is time to make a release. > > The intent then is to initiate 1.20 and immediate after that change > 'main' > > to 2.0. > > > > Going forward then all work on the 1.x line should be focused on > > maintaining existing features, dependencies, and helping 1.x users > migrate > > to the 2.x line. Otherwise, new feature work will happen on 'main' as it > > normally does and will come out in the NiFi 2.x release line. > > > > Please flag key outstanding items as we narrow down the release candidate > > for NiFi 1.20. > > > > Thanks > > Joe > > > > [1] https://lists.apache.org/thread/qo4vvdw46235y7vy2crcd6l4m11wl7jz > > >
Re: [discuss] NiFi 1.20 and NiFi 2.0
Joe / team, Question on this. I think it would be helpful to understand the desired timelines for the first 2.0.0 release. I know it's not strictly predictable, but having a sense of what the timing looks like is important to help understand the implications of a "maintenance only" 1.x line. The schedule would ideally come from the folks who are actively looking at / contributing to the 2.0 release. They probably have the best gauge as to "when" it might happen (under ideal conditions). One of the risks, of course, is if the 2.0 release stalls or delays. Having an idea of how 1.x might evolve for the users who are not necessarily early-adopters or those that need longer support tails. If 2.0 is delayed and 1.x looks unmaintained, there's a potential chance for the project to lose a bit of credibility. I know we don't anticipate this scenario, but if we had a plan for it, that would be reassuring. Maybe this was already addressed, I apologize if so. But if not, can we throw some darts on the calendar to help understand the ideal rollout of 2.0 on a timeline? And are there any adjustments for the scenario described above? Thanks in advance, /Adam On Mon, Jan 9, 2023 at 1:53 PM Joe Witt wrote: > Team, > > As David mentioned in [1] following a successful NiFi 2.0 release goal > planning - we are now going to start moving the 'main' line to be the NiFi > 2.0 line which will allow for the key work to take place. We will also > move niFi 1.x to its appropriate support line. > > It is also the case that we have nearly 100 JIRAs on NiFi 1.20 and we have > work in there including security items so it is time to make a release. > The intent then is to initiate 1.20 and immediate after that change 'main' > to 2.0. > > Going forward then all work on the 1.x line should be focused on > maintaining existing features, dependencies, and helping 1.x users migrate > to the 2.x line. Otherwise, new feature work will happen on 'main' as it > normally does and will come out in the NiFi 2.x release line. > > Please flag key outstanding items as we narrow down the release candidate > for NiFi 1.20. > > Thanks > Joe > > [1] https://lists.apache.org/thread/qo4vvdw46235y7vy2crcd6l4m11wl7jz >
[discuss] NiFi 1.20 and NiFi 2.0
Team, As David mentioned in [1] following a successful NiFi 2.0 release goal planning - we are now going to start moving the 'main' line to be the NiFi 2.0 line which will allow for the key work to take place. We will also move niFi 1.x to its appropriate support line. It is also the case that we have nearly 100 JIRAs on NiFi 1.20 and we have work in there including security items so it is time to make a release. The intent then is to initiate 1.20 and immediate after that change 'main' to 2.0. Going forward then all work on the 1.x line should be focused on maintaining existing features, dependencies, and helping 1.x users migrate to the 2.x line. Otherwise, new feature work will happen on 'main' as it normally does and will come out in the NiFi 2.x release line. Please flag key outstanding items as we narrow down the release candidate for NiFi 1.20. Thanks Joe [1] https://lists.apache.org/thread/qo4vvdw46235y7vy2crcd6l4m11wl7jz
