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 <a...@adamtaft.com> 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 <joew...@apache.org> 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 > > >
