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 > > > > > >
