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
