nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aldrin Piri <aldrinp...@gmail.com>
Subject Re: 1.0.0 Branch Guidance
Date Tue, 29 Sep 2015 14:47:01 GMT
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 <joe.witt@gmail.com> 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 <busbey@cloudera.com> 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 <dbress@onyxconsults.com>
> 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 <aldrinpiri@gmail.com>
> >> Sent: Tuesday, September 29, 2015 8:48 AM
> >> To: dev@nifi.apache.org
> >> 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 <dbress@onyxconsults.com>
> 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 <aldrinpiri@gmail.com>
> >>> Sent: Thursday, September 24, 2015 10:49 AM
> >>> To: dev@nifi.apache.org
> >>> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message