Personally, I think the discussion should happen on dev@ since there's a big impact on the project.
Agree that the results of the discussion should get captured on the wiki. -Sean On Tue, Sep 29, 2015 at 9:47 AM, Aldrin Piri <[email protected]> wrote: > 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 >> -- Sean
