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