Not sure if the place for discussion would be on the mailing threads or the accompanying wiki pages, but said pages should also capture/reflect the process.
Those in question are project roadmap [1] and feature proposals [2]. [1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=58851850 [2] https://cwiki.apache.org/confluence/display/NIFI/NiFi+Feature+Proposals On Tue, Sep 29, 2015 at 10:31 AM, Joe Witt <[email protected]> wrote: > Sean, > > Great points. I will spin each of those out into their own threads. > How about as those near consensus let's merge those results back into > this thread. > > Thread 1: What is the MVP for Apache NiFi 1.0.0? > > Thread 2: What sort of major release support plan do we want to provide? > > Thanks > Joe > > On Tue, Sep 29, 2015 at 9:50 AM, Sean Busbey <[email protected]> wrote: > > Before we make a 1.0 branch we should get consensus on what a > > minimally viable 1.0 release would need to contain and set a target > > release date (even if it's 6-9 months out). > > > > Otherwise it's too easy to end up in a situation where the 1.0 branch > > perpetually languishing while releases continue out of the older > > release line. > > > > Kind of related, how long do we plan to support major releases? Once > > 1.Y comes out, how long will we keep making 0.Xs? What about once > > there's a 2.Z? > > > > On Tue, Sep 29, 2015 at 7:58 AM, Dan Bress <[email protected]> > wrote: > >> OK, sounds good to me. If I had to choose between keeping most of the > communities work 'parked' as PullRequests and patches vs. merged into a 1.X > branch that we keep up to date with master, I'd vote for 1.X branch. > >> > >> Dan Bress > >> Software Engineer > >> ONYX Consulting Services > >> > >> ________________________________________ > >> From: Aldrin Piri <[email protected]> > >> Sent: Tuesday, September 29, 2015 8:48 AM > >> To: [email protected] > >> Subject: Re: 1.0.0 Branch Guidance > >> > >> Dan, > >> > >> I don't think we are at the point where 1.0 is our next release. The > items > >> to be included for that release as per the feature proposals (whether > >> directly as a feature or as an implicit dependency for one or more of > those > >> features) are some considerable efforts and while there may not be many > >> releases between 0.3.0 and that point, it will likely be too long to go > >> without any at all. > >> > >> Certainly agree on the long living branch being an effort of itself, but > >> may be the course we have to take to keep the project moving. > >> > >> On Tue, Sep 29, 2015 at 8:41 AM, Dan Bress <[email protected]> > wrote: > >> > >>> Aldrin, > >>> I definitely like the idea of creating separate branches for the > 0.3.X > >>> work and the 1.X.X work. > >>> > >>> My thoughts would be to make 'master' the 1.X version, and make a > >>> branch for the 0.3.X work. The reason being, I would imagine most of > the > >>> work the community is doing should be slated for 1.X, where as less > >>> work(e.g. bug fixes) be done in the 0.3.X branch. And by making master > >>> 1.0.0 it nudges people in that direction. Also, I'm assuming that > 0.3.X > >>> will just be bug fixes at this point, and our next 'major' release > will be > >>> 1.0.0. Is that a fair assumption to make? If not, I might be more > >>> inclined to agree with your original suggestion, although keeping that > long > >>> living branch up to date with all the changes from master might be a > >>> maintenance nightmare. > >>> > >>> Dan Bress > >>> Software Engineer > >>> ONYX Consulting Services > >>> > >>> ________________________________________ > >>> From: Aldrin Piri <[email protected]> > >>> Sent: Thursday, September 24, 2015 10:49 AM > >>> To: [email protected] > >>> Subject: 1.0.0 Branch Guidance > >>> > >>> All, > >>> > >>> We are starting to receive more items that are "breaking" changes > >>> (deprecation of components and code being those that immediately come > to > >>> mind) and are accordingly scheduled for a 1.0.0 release. I would like > to > >>> solicit the community for best practices on the introduction and > >>> maintenance of a 1.0.0 branch so we can do so in a practical manner. > >>> > >>> There are a few PRs/patches that are sitting in limbo because we do not > >>> have an appropriate place to put them and would very much like to be > able > >>> to incorporate those changes and close them in lieu of waiting until > master > >>> reaches that juncture. > >>> > >>> Any input on caveats, items to note, and any other items to be mindful > of > >>> is greatly appreciated. > >>> > >>> Thanks! > >>> > > > > > > > > -- > > Sean >
