You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Aldrin Piri <al...@gmail.com> on 2015/09/24 16:49:05 UTC
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!
Re: 1.0.0 Branch Guidance
Posted by Sean Busbey <bu...@cloudera.com>.
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 <al...@gmail.com> 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 <jo...@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 <bu...@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 <db...@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 <al...@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 <db...@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 <al...@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
>>
--
Sean
Re: 1.0.0 Branch Guidance
Posted by Aldrin Piri <al...@gmail.com>.
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 <jo...@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 <bu...@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 <db...@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 <al...@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 <db...@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 <al...@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
>
Re: 1.0.0 Branch Guidance
Posted by Joe Witt <jo...@gmail.com>.
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 <bu...@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 <db...@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 <al...@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 <db...@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 <al...@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
Re: 1.0.0 Branch Guidance
Posted by Sean Busbey <bu...@cloudera.com>.
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 <db...@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 <al...@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 <db...@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 <al...@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
Re: 1.0.0 Branch Guidance
Posted by Dan Bress <db...@onyxconsults.com>.
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 <al...@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 <db...@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 <al...@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!
>
Re: 1.0.0 Branch Guidance
Posted by Aldrin Piri <al...@gmail.com>.
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 <db...@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 <al...@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!
>
Re: 1.0.0 Branch Guidance
Posted by Dan Bress <db...@onyxconsults.com>.
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 <al...@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!