[DISCUSS] Apache NiFi 0.7.0 and 1.0.0

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

[DISCUSS] Apache NiFi 0.7.0 and 1.0.0

joewitt
Administrator
Team,

Want to start zeroing in on the details of the next releases.  We had
a good set of discussions around this back in January and have since
been executing along this general path [1].

On the 0.x line the next release would be 0.7.0.  There does appear to
be a lot of useful improvements/features/fixes there now and it is
time to do a release according to our general 6-8 week approach.
However, given all the effort going into 1.x I'd like to get a sense
of what the community preference is.

On the 1.0 line the release is coming into focus.  Some things have
moved into 1.x and some things look like they'd slide to the right of
1.x as is to be expected.  For example distributed durability (HA
Data) looks like a good thing to do post 1.0 given the substantive
changes present from the new HA clustering approach and multi-tenant
authorization.  I'd also like to dive in and liberally apply Apache
Yetus annotations [2] to all the things so we can be really explicit
about what parts we can more freely evolve going forward.  We've been
a bit awkwardly hamstrung thus far without these so they should help
greatly to better convey intent.

For those really interested in things coming in the 1.0 release please
take a look through the JIRAs currently there and provide comments on
what is important to you, what you'd like to see moved out, in, etc..
[3].  At this point there are still a lot of things which will likely
need to move out to allow the release to occur in a timely fashion.

Also, keep in mind our stated release line/support model as found here [4].

[1] http://mail-archives.apache.org/mod_mbox/nifi-dev/201601.mbox/%3CCALJK9a4dMw9PyrrihpPwM7DH3R_4v8b%3Dr--LDhK7y5scob-0og%40mail.gmail.com%3E

[2] https://yetus.apache.org/documentation/0.2.1/audience-annotations-apidocs/

[3] https://issues.apache.org/jira/browse/NIFI-1887?jql=fixVersion%20%3D%201.0.0%20AND%20project%20%3D%20NIFI

[4] https://cwiki.apache.org/confluence/display/NIFI/Git+Branching+and+Release+Line+Management

Thanks
Joe
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0

James Wing
I'm definitely in favor of releasing 0.7.0, but I don't think we need be
rigid about the schedule.  If delaying 0.7.0 a few weeks (2-4?) helps pace
us towards a 1.0 in mid- to late-Summer, that seems reasonable to me.  Do
we believe that is still a likely target?

Thanks,

James

On Tue, May 17, 2016 at 7:30 AM, Joe Witt <[hidden email]> wrote:

> Team,
>
> Want to start zeroing in on the details of the next releases.  We had
> a good set of discussions around this back in January and have since
> been executing along this general path [1].
>
> On the 0.x line the next release would be 0.7.0.  There does appear to
> be a lot of useful improvements/features/fixes there now and it is
> time to do a release according to our general 6-8 week approach.
> However, given all the effort going into 1.x I'd like to get a sense
> of what the community preference is.
>
> On the 1.0 line the release is coming into focus.  Some things have
> moved into 1.x and some things look like they'd slide to the right of
> 1.x as is to be expected.  For example distributed durability (HA
> Data) looks like a good thing to do post 1.0 given the substantive
> changes present from the new HA clustering approach and multi-tenant
> authorization.  I'd also like to dive in and liberally apply Apache
> Yetus annotations [2] to all the things so we can be really explicit
> about what parts we can more freely evolve going forward.  We've been
> a bit awkwardly hamstrung thus far without these so they should help
> greatly to better convey intent.
>
> For those really interested in things coming in the 1.0 release please
> take a look through the JIRAs currently there and provide comments on
> what is important to you, what you'd like to see moved out, in, etc..
> [3].  At this point there are still a lot of things which will likely
> need to move out to allow the release to occur in a timely fashion.
>
> Also, keep in mind our stated release line/support model as found here [4].
>
> [1]
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201601.mbox/%3CCALJK9a4dMw9PyrrihpPwM7DH3R_4v8b%3Dr--LDhK7y5scob-0og%40mail.gmail.com%3E
>
> [2]
> https://yetus.apache.org/documentation/0.2.1/audience-annotations-apidocs/
>
> [3]
> https://issues.apache.org/jira/browse/NIFI-1887?jql=fixVersion%20%3D%201.0.0%20AND%20project%20%3D%20NIFI
>
> [4]
> https://cwiki.apache.org/confluence/display/NIFI/Git+Branching+and+Release+Line+Management
>
> Thanks
> Joe
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0

Oleg Zhurakousky
Agreed! I would like to see 0.7 within 2-3 weeks as there are a lot of improvements and new features/components in it already, and would like to give it some miles before 1.0.

Oleg

> On May 17, 2016, at 4:02 PM, James Wing <[hidden email]> wrote:
>
> I'm definitely in favor of releasing 0.7.0, but I don't think we need be
> rigid about the schedule.  If delaying 0.7.0 a few weeks (2-4?) helps pace
> us towards a 1.0 in mid- to late-Summer, that seems reasonable to me.  Do
> we believe that is still a likely target?
>
> Thanks,
>
> James
>
> On Tue, May 17, 2016 at 7:30 AM, Joe Witt <[hidden email]> wrote:
>
>> Team,
>>
>> Want to start zeroing in on the details of the next releases.  We had
>> a good set of discussions around this back in January and have since
>> been executing along this general path [1].
>>
>> On the 0.x line the next release would be 0.7.0.  There does appear to
>> be a lot of useful improvements/features/fixes there now and it is
>> time to do a release according to our general 6-8 week approach.
>> However, given all the effort going into 1.x I'd like to get a sense
>> of what the community preference is.
>>
>> On the 1.0 line the release is coming into focus.  Some things have
>> moved into 1.x and some things look like they'd slide to the right of
>> 1.x as is to be expected.  For example distributed durability (HA
>> Data) looks like a good thing to do post 1.0 given the substantive
>> changes present from the new HA clustering approach and multi-tenant
>> authorization.  I'd also like to dive in and liberally apply Apache
>> Yetus annotations [2] to all the things so we can be really explicit
>> about what parts we can more freely evolve going forward.  We've been
>> a bit awkwardly hamstrung thus far without these so they should help
>> greatly to better convey intent.
>>
>> For those really interested in things coming in the 1.0 release please
>> take a look through the JIRAs currently there and provide comments on
>> what is important to you, what you'd like to see moved out, in, etc..
>> [3].  At this point there are still a lot of things which will likely
>> need to move out to allow the release to occur in a timely fashion.
>>
>> Also, keep in mind our stated release line/support model as found here [4].
>>
>> [1]
>> http://mail-archives.apache.org/mod_mbox/nifi-dev/201601.mbox/%3CCALJK9a4dMw9PyrrihpPwM7DH3R_4v8b%3Dr--LDhK7y5scob-0og%40mail.gmail.com%3E
>>
>> [2]
>> https://yetus.apache.org/documentation/0.2.1/audience-annotations-apidocs/
>>
>> [3]
>> https://issues.apache.org/jira/browse/NIFI-1887?jql=fixVersion%20%3D%201.0.0%20AND%20project%20%3D%20NIFI
>>
>> [4]
>> https://cwiki.apache.org/confluence/display/NIFI/Git+Branching+and+Release+Line+Management
>>
>> Thanks
>> Joe
>>

Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0

Joe Witt
Ok - i'm good with an 0.7 release too and think it is a good idea.  I
am happy to RM the release.

I'd like to select a date at which we're happy to call the 0.x line
then feature complete which means 0.7 would be the last feature
bearing 0.x release and from then on it would be bug fixes only
consistent withe support model.  To do that I think we should feel
reasonably confident that the 1.x release is close.  So let's say we
did an 0.7 release early June - say first week of June.  I'd like us
to say then that 1.x is targeted to early July.

If this seems like a reasonable path I'll start filling out the
tragically never updated roadmap wiki page [1] with the 0.7 target,
1.x target, and put some placeholder/tentatives for the 1.1 and beyond
targets.  Will wait for additional inputs.

[1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=58851850

Thanks
Joe

On Tue, May 17, 2016 at 4:15 PM, Oleg Zhurakousky
<[hidden email]> wrote:

> Agreed! I would like to see 0.7 within 2-3 weeks as there are a lot of improvements and new features/components in it already, and would like to give it some miles before 1.0.
>
> Oleg
>> On May 17, 2016, at 4:02 PM, James Wing <[hidden email]> wrote:
>>
>> I'm definitely in favor of releasing 0.7.0, but I don't think we need be
>> rigid about the schedule.  If delaying 0.7.0 a few weeks (2-4?) helps pace
>> us towards a 1.0 in mid- to late-Summer, that seems reasonable to me.  Do
>> we believe that is still a likely target?
>>
>> Thanks,
>>
>> James
>>
>> On Tue, May 17, 2016 at 7:30 AM, Joe Witt <[hidden email]> wrote:
>>
>>> Team,
>>>
>>> Want to start zeroing in on the details of the next releases.  We had
>>> a good set of discussions around this back in January and have since
>>> been executing along this general path [1].
>>>
>>> On the 0.x line the next release would be 0.7.0.  There does appear to
>>> be a lot of useful improvements/features/fixes there now and it is
>>> time to do a release according to our general 6-8 week approach.
>>> However, given all the effort going into 1.x I'd like to get a sense
>>> of what the community preference is.
>>>
>>> On the 1.0 line the release is coming into focus.  Some things have
>>> moved into 1.x and some things look like they'd slide to the right of
>>> 1.x as is to be expected.  For example distributed durability (HA
>>> Data) looks like a good thing to do post 1.0 given the substantive
>>> changes present from the new HA clustering approach and multi-tenant
>>> authorization.  I'd also like to dive in and liberally apply Apache
>>> Yetus annotations [2] to all the things so we can be really explicit
>>> about what parts we can more freely evolve going forward.  We've been
>>> a bit awkwardly hamstrung thus far without these so they should help
>>> greatly to better convey intent.
>>>
>>> For those really interested in things coming in the 1.0 release please
>>> take a look through the JIRAs currently there and provide comments on
>>> what is important to you, what you'd like to see moved out, in, etc..
>>> [3].  At this point there are still a lot of things which will likely
>>> need to move out to allow the release to occur in a timely fashion.
>>>
>>> Also, keep in mind our stated release line/support model as found here [4].
>>>
>>> [1]
>>> http://mail-archives.apache.org/mod_mbox/nifi-dev/201601.mbox/%3CCALJK9a4dMw9PyrrihpPwM7DH3R_4v8b%3Dr--LDhK7y5scob-0og%40mail.gmail.com%3E
>>>
>>> [2]
>>> https://yetus.apache.org/documentation/0.2.1/audience-annotations-apidocs/
>>>
>>> [3]
>>> https://issues.apache.org/jira/browse/NIFI-1887?jql=fixVersion%20%3D%201.0.0%20AND%20project%20%3D%20NIFI
>>>
>>> [4]
>>> https://cwiki.apache.org/confluence/display/NIFI/Git+Branching+and+Release+Line+Management
>>>
>>> Thanks
>>> Joe
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0

Andy LoPresto-2
This schedule seems appropriate to me. Once 0.7.0 is released and we confirm the release date for 1.0, feature development is completely targeted to 1.0, correct? Security and data loss bug fixes would still be backported, but new features would not. 

Andy LoPresto
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On May 17, 2016, at 1:19 PM, Joe Witt <[hidden email]> wrote:

Ok - i'm good with an 0.7 release too and think it is a good idea.  I
am happy to RM the release.

I'd like to select a date at which we're happy to call the 0.x line
then feature complete which means 0.7 would be the last feature
bearing 0.x release and from then on it would be bug fixes only
consistent withe support model.  To do that I think we should feel
reasonably confident that the 1.x release is close.  So let's say we
did an 0.7 release early June - say first week of June.  I'd like us
to say then that 1.x is targeted to early July.

If this seems like a reasonable path I'll start filling out the
tragically never updated roadmap wiki page [1] with the 0.7 target,
1.x target, and put some placeholder/tentatives for the 1.1 and beyond
targets.  Will wait for additional inputs.

[1] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=58851850

Thanks
Joe

On Tue, May 17, 2016 at 4:15 PM, Oleg Zhurakousky
<[hidden email]> wrote:
Agreed! I would like to see 0.7 within 2-3 weeks as there are a lot of improvements and new features/components in it already, and would like to give it some miles before 1.0.

Oleg
On May 17, 2016, at 4:02 PM, James Wing <[hidden email]> wrote:

I'm definitely in favor of releasing 0.7.0, but I don't think we need be
rigid about the schedule.  If delaying 0.7.0 a few weeks (2-4?) helps pace
us towards a 1.0 in mid- to late-Summer, that seems reasonable to me.  Do
we believe that is still a likely target?

Thanks,

James

On Tue, May 17, 2016 at 7:30 AM, Joe Witt <[hidden email]> wrote:

Team,

Want to start zeroing in on the details of the next releases.  We had
a good set of discussions around this back in January and have since
been executing along this general path [1].

On the 0.x line the next release would be 0.7.0.  There does appear to
be a lot of useful improvements/features/fixes there now and it is
time to do a release according to our general 6-8 week approach.
However, given all the effort going into 1.x I'd like to get a sense
of what the community preference is.

On the 1.0 line the release is coming into focus.  Some things have
moved into 1.x and some things look like they'd slide to the right of
1.x as is to be expected.  For example distributed durability (HA
Data) looks like a good thing to do post 1.0 given the substantive
changes present from the new HA clustering approach and multi-tenant
authorization.  I'd also like to dive in and liberally apply Apache
Yetus annotations [2] to all the things so we can be really explicit
about what parts we can more freely evolve going forward.  We've been
a bit awkwardly hamstrung thus far without these so they should help
greatly to better convey intent.

For those really interested in things coming in the 1.0 release please
take a look through the JIRAs currently there and provide comments on
what is important to you, what you'd like to see moved out, in, etc..
[3].  At this point there are still a lot of things which will likely
need to move out to allow the release to occur in a timely fashion.

Also, keep in mind our stated release line/support model as found here [4].

[1]
http://mail-archives.apache.org/mod_mbox/nifi-dev/201601.mbox/%3CCALJK9a4dMw9PyrrihpPwM7DH3R_4v8b%3Dr--LDhK7y5scob-0og%40mail.gmail.com%3E

[2]
https://yetus.apache.org/documentation/0.2.1/audience-annotations-apidocs/

[3]
https://issues.apache.org/jira/browse/NIFI-1887?jql=fixVersion%20%3D%201.0.0%20AND%20project%20%3D%20NIFI

[4]
https://cwiki.apache.org/confluence/display/NIFI/Git+Branching+and+Release+Line+Management

Thanks
Joe




signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0

Joe Witt
I believe that is right Andy.  The support guide articulates that we
could do a feature release upon request if there was some specific
need a community member had but that otherwise the only releases on an
older line still supported would be focused on security/data loss type
items.

Thanks
Joe

On Tue, May 17, 2016 at 4:58 PM, Andy LoPresto <[hidden email]> wrote:

> This schedule seems appropriate to me. Once 0.7.0 is released and we confirm
> the release date for 1.0, feature development is completely targeted to 1.0,
> correct? Security and data loss bug fixes would still be backported, but new
> features would not.
>
> Andy LoPresto
> [hidden email]
> [hidden email]
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On May 17, 2016, at 1:19 PM, Joe Witt <[hidden email]> wrote:
>
> Ok - i'm good with an 0.7 release too and think it is a good idea.  I
> am happy to RM the release.
>
> I'd like to select a date at which we're happy to call the 0.x line
> then feature complete which means 0.7 would be the last feature
> bearing 0.x release and from then on it would be bug fixes only
> consistent withe support model.  To do that I think we should feel
> reasonably confident that the 1.x release is close.  So let's say we
> did an 0.7 release early June - say first week of June.  I'd like us
> to say then that 1.x is targeted to early July.
>
> If this seems like a reasonable path I'll start filling out the
> tragically never updated roadmap wiki page [1] with the 0.7 target,
> 1.x target, and put some placeholder/tentatives for the 1.1 and beyond
> targets.  Will wait for additional inputs.
>
> [1]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=58851850
>
> Thanks
> Joe
>
> On Tue, May 17, 2016 at 4:15 PM, Oleg Zhurakousky
> <[hidden email]> wrote:
>
> Agreed! I would like to see 0.7 within 2-3 weeks as there are a lot of
> improvements and new features/components in it already, and would like to
> give it some miles before 1.0.
>
> Oleg
>
> On May 17, 2016, at 4:02 PM, James Wing <[hidden email]> wrote:
>
> I'm definitely in favor of releasing 0.7.0, but I don't think we need be
> rigid about the schedule.  If delaying 0.7.0 a few weeks (2-4?) helps pace
> us towards a 1.0 in mid- to late-Summer, that seems reasonable to me.  Do
> we believe that is still a likely target?
>
> Thanks,
>
> James
>
> On Tue, May 17, 2016 at 7:30 AM, Joe Witt <[hidden email]> wrote:
>
> Team,
>
> Want to start zeroing in on the details of the next releases.  We had
> a good set of discussions around this back in January and have since
> been executing along this general path [1].
>
> On the 0.x line the next release would be 0.7.0.  There does appear to
> be a lot of useful improvements/features/fixes there now and it is
> time to do a release according to our general 6-8 week approach.
> However, given all the effort going into 1.x I'd like to get a sense
> of what the community preference is.
>
> On the 1.0 line the release is coming into focus.  Some things have
> moved into 1.x and some things look like they'd slide to the right of
> 1.x as is to be expected.  For example distributed durability (HA
> Data) looks like a good thing to do post 1.0 given the substantive
> changes present from the new HA clustering approach and multi-tenant
> authorization.  I'd also like to dive in and liberally apply Apache
> Yetus annotations [2] to all the things so we can be really explicit
> about what parts we can more freely evolve going forward.  We've been
> a bit awkwardly hamstrung thus far without these so they should help
> greatly to better convey intent.
>
> For those really interested in things coming in the 1.0 release please
> take a look through the JIRAs currently there and provide comments on
> what is important to you, what you'd like to see moved out, in, etc..
> [3].  At this point there are still a lot of things which will likely
> need to move out to allow the release to occur in a timely fashion.
>
> Also, keep in mind our stated release line/support model as found here [4].
>
> [1]
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201601.mbox/%3CCALJK9a4dMw9PyrrihpPwM7DH3R_4v8b%3Dr--LDhK7y5scob-0og%40mail.gmail.com%3E
>
> [2]
> https://yetus.apache.org/documentation/0.2.1/audience-annotations-apidocs/
>
> [3]
> https://issues.apache.org/jira/browse/NIFI-1887?jql=fixVersion%20%3D%201.0.0%20AND%20project%20%3D%20NIFI
>
> [4]
> https://cwiki.apache.org/confluence/display/NIFI/Git+Branching+and+Release+Line+Management
>
> Thanks
> Joe
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0

Michael Moser
The way I read the release support document, I don't think the feature
cut-off for the 0.x branch happens when we confirm a release date for 1.0,
I think it occurs once we actually release 1.0.  Maybe the cut-off can
happen once we declare the first 1.0 release candidate.  I'm sure we will
spend significant time doing testing and bug fixes on 1.0 release
candidates.  If I recall, we spent 2 weeks on 0.6.1 release candidates.

-- Mike


On Tue, May 17, 2016 at 6:04 PM, Joe Witt <[hidden email]> wrote:

> I believe that is right Andy.  The support guide articulates that we
> could do a feature release upon request if there was some specific
> need a community member had but that otherwise the only releases on an
> older line still supported would be focused on security/data loss type
> items.
>
> Thanks
> Joe
>
> On Tue, May 17, 2016 at 4:58 PM, Andy LoPresto <[hidden email]>
> wrote:
> > This schedule seems appropriate to me. Once 0.7.0 is released and we
> confirm
> > the release date for 1.0, feature development is completely targeted to
> 1.0,
> > correct? Security and data loss bug fixes would still be backported, but
> new
> > features would not.
> >
> > Andy LoPresto
> > [hidden email]
> > [hidden email]
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >
> > On May 17, 2016, at 1:19 PM, Joe Witt <[hidden email]> wrote:
> >
> > Ok - i'm good with an 0.7 release too and think it is a good idea.  I
> > am happy to RM the release.
> >
> > I'd like to select a date at which we're happy to call the 0.x line
> > then feature complete which means 0.7 would be the last feature
> > bearing 0.x release and from then on it would be bug fixes only
> > consistent withe support model.  To do that I think we should feel
> > reasonably confident that the 1.x release is close.  So let's say we
> > did an 0.7 release early June - say first week of June.  I'd like us
> > to say then that 1.x is targeted to early July.
> >
> > If this seems like a reasonable path I'll start filling out the
> > tragically never updated roadmap wiki page [1] with the 0.7 target,
> > 1.x target, and put some placeholder/tentatives for the 1.1 and beyond
> > targets.  Will wait for additional inputs.
> >
> > [1]
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=58851850
> >
> > Thanks
> > Joe
> >
> > On Tue, May 17, 2016 at 4:15 PM, Oleg Zhurakousky
> > <[hidden email]> wrote:
> >
> > Agreed! I would like to see 0.7 within 2-3 weeks as there are a lot of
> > improvements and new features/components in it already, and would like to
> > give it some miles before 1.0.
> >
> > Oleg
> >
> > On May 17, 2016, at 4:02 PM, James Wing <[hidden email]> wrote:
> >
> > I'm definitely in favor of releasing 0.7.0, but I don't think we need be
> > rigid about the schedule.  If delaying 0.7.0 a few weeks (2-4?) helps
> pace
> > us towards a 1.0 in mid- to late-Summer, that seems reasonable to me.  Do
> > we believe that is still a likely target?
> >
> > Thanks,
> >
> > James
> >
> > On Tue, May 17, 2016 at 7:30 AM, Joe Witt <[hidden email]> wrote:
> >
> > Team,
> >
> > Want to start zeroing in on the details of the next releases.  We had
> > a good set of discussions around this back in January and have since
> > been executing along this general path [1].
> >
> > On the 0.x line the next release would be 0.7.0.  There does appear to
> > be a lot of useful improvements/features/fixes there now and it is
> > time to do a release according to our general 6-8 week approach.
> > However, given all the effort going into 1.x I'd like to get a sense
> > of what the community preference is.
> >
> > On the 1.0 line the release is coming into focus.  Some things have
> > moved into 1.x and some things look like they'd slide to the right of
> > 1.x as is to be expected.  For example distributed durability (HA
> > Data) looks like a good thing to do post 1.0 given the substantive
> > changes present from the new HA clustering approach and multi-tenant
> > authorization.  I'd also like to dive in and liberally apply Apache
> > Yetus annotations [2] to all the things so we can be really explicit
> > about what parts we can more freely evolve going forward.  We've been
> > a bit awkwardly hamstrung thus far without these so they should help
> > greatly to better convey intent.
> >
> > For those really interested in things coming in the 1.0 release please
> > take a look through the JIRAs currently there and provide comments on
> > what is important to you, what you'd like to see moved out, in, etc..
> > [3].  At this point there are still a lot of things which will likely
> > need to move out to allow the release to occur in a timely fashion.
> >
> > Also, keep in mind our stated release line/support model as found here
> [4].
> >
> > [1]
> >
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201601.mbox/%3CCALJK9a4dMw9PyrrihpPwM7DH3R_4v8b%3Dr--LDhK7y5scob-0og%40mail.gmail.com%3E
> >
> > [2]
> >
> https://yetus.apache.org/documentation/0.2.1/audience-annotations-apidocs/
> >
> > [3]
> >
> https://issues.apache.org/jira/browse/NIFI-1887?jql=fixVersion%20%3D%201.0.0%20AND%20project%20%3D%20NIFI
> >
> > [4]
> >
> https://cwiki.apache.org/confluence/display/NIFI/Git+Branching+and+Release+Line+Management
> >
> > Thanks
> > Joe
> >
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0

Joe Witt
Mike

I agree with the letter of the reading so this thread is to discuss
the spirit of it and how to best apply it to our situation and
community now.  Whether it is 'just before' or 'just after' or 'same
time' I think it is within the intent.  I just want us to be clear
what it is.  It is extra work to ensure each PR is applied to both
lines and extra work increases contributor and reviewer burden so we
should be mindful of that as it is a dragging force.  We also need to
keep in mind that with 1.x we have Java 8 as a minimum and so there
are cases which will not apply to both and we don't want folks to
avoid using Java 8 features just so it can apply to both.

My preference is that we have 0.7 as the last planned feature release
in 0.x and with that in mind we need to choose to have it be a bit
before, a bit after, or at the same time as the 1.x release.  I
personally am comfortable with what I proposed for 0.7 vs 1.0 timing
but I am fine if the consensus is to release the last 0.x and 1.0 at
the same time.  Just hoping to avoid needing to have another feature
release on 0.x after 0.7 other than some special request that might
come up later (which is also discussed in the support doc).

I also agree the release process for 1.0 will be significant as it
will include important new features.  Definitely need folks testing
out and providing feedback on the features early and often.

Thanks
Joe

On Tue, May 17, 2016 at 6:20 PM, Michael Moser <[hidden email]> wrote:

> The way I read the release support document, I don't think the feature
> cut-off for the 0.x branch happens when we confirm a release date for 1.0,
> I think it occurs once we actually release 1.0.  Maybe the cut-off can
> happen once we declare the first 1.0 release candidate.  I'm sure we will
> spend significant time doing testing and bug fixes on 1.0 release
> candidates.  If I recall, we spent 2 weeks on 0.6.1 release candidates.
>
> -- Mike
>
>
> On Tue, May 17, 2016 at 6:04 PM, Joe Witt <[hidden email]> wrote:
>
>> I believe that is right Andy.  The support guide articulates that we
>> could do a feature release upon request if there was some specific
>> need a community member had but that otherwise the only releases on an
>> older line still supported would be focused on security/data loss type
>> items.
>>
>> Thanks
>> Joe
>>
>> On Tue, May 17, 2016 at 4:58 PM, Andy LoPresto <[hidden email]>
>> wrote:
>> > This schedule seems appropriate to me. Once 0.7.0 is released and we
>> confirm
>> > the release date for 1.0, feature development is completely targeted to
>> 1.0,
>> > correct? Security and data loss bug fixes would still be backported, but
>> new
>> > features would not.
>> >
>> > Andy LoPresto
>> > [hidden email]
>> > [hidden email]
>> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>> >
>> > On May 17, 2016, at 1:19 PM, Joe Witt <[hidden email]> wrote:
>> >
>> > Ok - i'm good with an 0.7 release too and think it is a good idea.  I
>> > am happy to RM the release.
>> >
>> > I'd like to select a date at which we're happy to call the 0.x line
>> > then feature complete which means 0.7 would be the last feature
>> > bearing 0.x release and from then on it would be bug fixes only
>> > consistent withe support model.  To do that I think we should feel
>> > reasonably confident that the 1.x release is close.  So let's say we
>> > did an 0.7 release early June - say first week of June.  I'd like us
>> > to say then that 1.x is targeted to early July.
>> >
>> > If this seems like a reasonable path I'll start filling out the
>> > tragically never updated roadmap wiki page [1] with the 0.7 target,
>> > 1.x target, and put some placeholder/tentatives for the 1.1 and beyond
>> > targets.  Will wait for additional inputs.
>> >
>> > [1]
>> >
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=58851850
>> >
>> > Thanks
>> > Joe
>> >
>> > On Tue, May 17, 2016 at 4:15 PM, Oleg Zhurakousky
>> > <[hidden email]> wrote:
>> >
>> > Agreed! I would like to see 0.7 within 2-3 weeks as there are a lot of
>> > improvements and new features/components in it already, and would like to
>> > give it some miles before 1.0.
>> >
>> > Oleg
>> >
>> > On May 17, 2016, at 4:02 PM, James Wing <[hidden email]> wrote:
>> >
>> > I'm definitely in favor of releasing 0.7.0, but I don't think we need be
>> > rigid about the schedule.  If delaying 0.7.0 a few weeks (2-4?) helps
>> pace
>> > us towards a 1.0 in mid- to late-Summer, that seems reasonable to me.  Do
>> > we believe that is still a likely target?
>> >
>> > Thanks,
>> >
>> > James
>> >
>> > On Tue, May 17, 2016 at 7:30 AM, Joe Witt <[hidden email]> wrote:
>> >
>> > Team,
>> >
>> > Want to start zeroing in on the details of the next releases.  We had
>> > a good set of discussions around this back in January and have since
>> > been executing along this general path [1].
>> >
>> > On the 0.x line the next release would be 0.7.0.  There does appear to
>> > be a lot of useful improvements/features/fixes there now and it is
>> > time to do a release according to our general 6-8 week approach.
>> > However, given all the effort going into 1.x I'd like to get a sense
>> > of what the community preference is.
>> >
>> > On the 1.0 line the release is coming into focus.  Some things have
>> > moved into 1.x and some things look like they'd slide to the right of
>> > 1.x as is to be expected.  For example distributed durability (HA
>> > Data) looks like a good thing to do post 1.0 given the substantive
>> > changes present from the new HA clustering approach and multi-tenant
>> > authorization.  I'd also like to dive in and liberally apply Apache
>> > Yetus annotations [2] to all the things so we can be really explicit
>> > about what parts we can more freely evolve going forward.  We've been
>> > a bit awkwardly hamstrung thus far without these so they should help
>> > greatly to better convey intent.
>> >
>> > For those really interested in things coming in the 1.0 release please
>> > take a look through the JIRAs currently there and provide comments on
>> > what is important to you, what you'd like to see moved out, in, etc..
>> > [3].  At this point there are still a lot of things which will likely
>> > need to move out to allow the release to occur in a timely fashion.
>> >
>> > Also, keep in mind our stated release line/support model as found here
>> [4].
>> >
>> > [1]
>> >
>> http://mail-archives.apache.org/mod_mbox/nifi-dev/201601.mbox/%3CCALJK9a4dMw9PyrrihpPwM7DH3R_4v8b%3Dr--LDhK7y5scob-0og%40mail.gmail.com%3E
>> >
>> > [2]
>> >
>> https://yetus.apache.org/documentation/0.2.1/audience-annotations-apidocs/
>> >
>> > [3]
>> >
>> https://issues.apache.org/jira/browse/NIFI-1887?jql=fixVersion%20%3D%201.0.0%20AND%20project%20%3D%20NIFI
>> >
>> > [4]
>> >
>> https://cwiki.apache.org/confluence/display/NIFI/Git+Branching+and+Release+Line+Management
>> >
>> > Thanks
>> > Joe
>> >
>> >
>> >
>>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0

Andy LoPresto-2
I think Mike’s read on the published guidelines is correct, but I agree with Joe that if we release 0.7 two weeks before 1.0, feature development that is merged after 0.7 does not need to be backported. Maybe this is something we should clarify on the wiki once we reach a consensus. 


Andy LoPresto
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On May 17, 2016, at 3:43 PM, Joe Witt <[hidden email]> wrote:

Mike

I agree with the letter of the reading so this thread is to discuss
the spirit of it and how to best apply it to our situation and
community now.  Whether it is 'just before' or 'just after' or 'same
time' I think it is within the intent.  I just want us to be clear
what it is.  It is extra work to ensure each PR is applied to both
lines and extra work increases contributor and reviewer burden so we
should be mindful of that as it is a dragging force.  We also need to
keep in mind that with 1.x we have Java 8 as a minimum and so there
are cases which will not apply to both and we don't want folks to
avoid using Java 8 features just so it can apply to both.

My preference is that we have 0.7 as the last planned feature release
in 0.x and with that in mind we need to choose to have it be a bit
before, a bit after, or at the same time as the 1.x release.  I
personally am comfortable with what I proposed for 0.7 vs 1.0 timing
but I am fine if the consensus is to release the last 0.x and 1.0 at
the same time.  Just hoping to avoid needing to have another feature
release on 0.x after 0.7 other than some special request that might
come up later (which is also discussed in the support doc).

I also agree the release process for 1.0 will be significant as it
will include important new features.  Definitely need folks testing
out and providing feedback on the features early and often.

Thanks
Joe

On Tue, May 17, 2016 at 6:20 PM, Michael Moser <[hidden email]> wrote:
The way I read the release support document, I don't think the feature
cut-off for the 0.x branch happens when we confirm a release date for 1.0,
I think it occurs once we actually release 1.0.  Maybe the cut-off can
happen once we declare the first 1.0 release candidate.  I'm sure we will
spend significant time doing testing and bug fixes on 1.0 release
candidates.  If I recall, we spent 2 weeks on 0.6.1 release candidates.

-- Mike


On Tue, May 17, 2016 at 6:04 PM, Joe Witt <[hidden email]> wrote:

I believe that is right Andy.  The support guide articulates that we
could do a feature release upon request if there was some specific
need a community member had but that otherwise the only releases on an
older line still supported would be focused on security/data loss type
items.

Thanks
Joe

On Tue, May 17, 2016 at 4:58 PM, Andy LoPresto <[hidden email]>
wrote:
This schedule seems appropriate to me. Once 0.7.0 is released and we
confirm
the release date for 1.0, feature development is completely targeted to
1.0,
correct? Security and data loss bug fixes would still be backported, but
new
features would not.

Andy LoPresto
[hidden email]
[hidden email]
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On May 17, 2016, at 1:19 PM, Joe Witt <[hidden email]> wrote:

Ok - i'm good with an 0.7 release too and think it is a good idea.  I
am happy to RM the release.

I'd like to select a date at which we're happy to call the 0.x line
then feature complete which means 0.7 would be the last feature
bearing 0.x release and from then on it would be bug fixes only
consistent withe support model.  To do that I think we should feel
reasonably confident that the 1.x release is close.  So let's say we
did an 0.7 release early June - say first week of June.  I'd like us
to say then that 1.x is targeted to early July.

If this seems like a reasonable path I'll start filling out the
tragically never updated roadmap wiki page [1] with the 0.7 target,
1.x target, and put some placeholder/tentatives for the 1.1 and beyond
targets.  Will wait for additional inputs.

[1]

https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=58851850

Thanks
Joe

On Tue, May 17, 2016 at 4:15 PM, Oleg Zhurakousky
<[hidden email]> wrote:

Agreed! I would like to see 0.7 within 2-3 weeks as there are a lot of
improvements and new features/components in it already, and would like to
give it some miles before 1.0.

Oleg

On May 17, 2016, at 4:02 PM, James Wing <[hidden email]> wrote:

I'm definitely in favor of releasing 0.7.0, but I don't think we need be
rigid about the schedule.  If delaying 0.7.0 a few weeks (2-4?) helps
pace
us towards a 1.0 in mid- to late-Summer, that seems reasonable to me.  Do
we believe that is still a likely target?

Thanks,

James

On Tue, May 17, 2016 at 7:30 AM, Joe Witt <[hidden email]> wrote:

Team,

Want to start zeroing in on the details of the next releases.  We had
a good set of discussions around this back in January and have since
been executing along this general path [1].

On the 0.x line the next release would be 0.7.0.  There does appear to
be a lot of useful improvements/features/fixes there now and it is
time to do a release according to our general 6-8 week approach.
However, given all the effort going into 1.x I'd like to get a sense
of what the community preference is.

On the 1.0 line the release is coming into focus.  Some things have
moved into 1.x and some things look like they'd slide to the right of
1.x as is to be expected.  For example distributed durability (HA
Data) looks like a good thing to do post 1.0 given the substantive
changes present from the new HA clustering approach and multi-tenant
authorization.  I'd also like to dive in and liberally apply Apache
Yetus annotations [2] to all the things so we can be really explicit
about what parts we can more freely evolve going forward.  We've been
a bit awkwardly hamstrung thus far without these so they should help
greatly to better convey intent.

For those really interested in things coming in the 1.0 release please
take a look through the JIRAs currently there and provide comments on
what is important to you, what you'd like to see moved out, in, etc..
[3].  At this point there are still a lot of things which will likely
need to move out to allow the release to occur in a timely fashion.

Also, keep in mind our stated release line/support model as found here
[4].

[1]

http://mail-archives.apache.org/mod_mbox/nifi-dev/201601.mbox/%3CCALJK9a4dMw9PyrrihpPwM7DH3R_4v8b%3Dr--LDhK7y5scob-0og%40mail.gmail.com%3E

[2]

https://yetus.apache.org/documentation/0.2.1/audience-annotations-apidocs/

[3]

https://issues.apache.org/jira/browse/NIFI-1887?jql=fixVersion%20%3D%201.0.0%20AND%20project%20%3D%20NIFI

[4]

https://cwiki.apache.org/confluence/display/NIFI/Git+Branching+and+Release+Line+Management

Thanks
Joe






signature.asc (859 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0

Joe Witt
Ok just to wrap up this thread. Will push a couple efforts
1) Will start pulling together an 0.7 release
2) Will update the roadmap slide to put in tentative timing/major
elements in the roadmap on the wiki page

And as for whether 0.7 ends up being the last release of the 0.x line
will just depend on 1.0 release timing and community interest in doing
an 0.8.  We don't have to decide that now.

Thanks
Joe

On Tue, May 17, 2016 at 7:12 PM, Andy LoPresto <[hidden email]> wrote:

> I think Mike’s read on the published guidelines is correct, but I agree with
> Joe that if we release 0.7 two weeks before 1.0, feature development that is
> merged after 0.7 does not need to be backported. Maybe this is something we
> should clarify on the wiki once we reach a consensus.
>
>
> Andy LoPresto
> [hidden email]
> [hidden email]
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On May 17, 2016, at 3:43 PM, Joe Witt <[hidden email]> wrote:
>
> Mike
>
> I agree with the letter of the reading so this thread is to discuss
> the spirit of it and how to best apply it to our situation and
> community now.  Whether it is 'just before' or 'just after' or 'same
> time' I think it is within the intent.  I just want us to be clear
> what it is.  It is extra work to ensure each PR is applied to both
> lines and extra work increases contributor and reviewer burden so we
> should be mindful of that as it is a dragging force.  We also need to
> keep in mind that with 1.x we have Java 8 as a minimum and so there
> are cases which will not apply to both and we don't want folks to
> avoid using Java 8 features just so it can apply to both.
>
> My preference is that we have 0.7 as the last planned feature release
> in 0.x and with that in mind we need to choose to have it be a bit
> before, a bit after, or at the same time as the 1.x release.  I
> personally am comfortable with what I proposed for 0.7 vs 1.0 timing
> but I am fine if the consensus is to release the last 0.x and 1.0 at
> the same time.  Just hoping to avoid needing to have another feature
> release on 0.x after 0.7 other than some special request that might
> come up later (which is also discussed in the support doc).
>
> I also agree the release process for 1.0 will be significant as it
> will include important new features.  Definitely need folks testing
> out and providing feedback on the features early and often.
>
> Thanks
> Joe
>
> On Tue, May 17, 2016 at 6:20 PM, Michael Moser <[hidden email]> wrote:
>
> The way I read the release support document, I don't think the feature
> cut-off for the 0.x branch happens when we confirm a release date for 1.0,
> I think it occurs once we actually release 1.0.  Maybe the cut-off can
> happen once we declare the first 1.0 release candidate.  I'm sure we will
> spend significant time doing testing and bug fixes on 1.0 release
> candidates.  If I recall, we spent 2 weeks on 0.6.1 release candidates.
>
> -- Mike
>
>
> On Tue, May 17, 2016 at 6:04 PM, Joe Witt <[hidden email]> wrote:
>
> I believe that is right Andy.  The support guide articulates that we
> could do a feature release upon request if there was some specific
> need a community member had but that otherwise the only releases on an
> older line still supported would be focused on security/data loss type
> items.
>
> Thanks
> Joe
>
> On Tue, May 17, 2016 at 4:58 PM, Andy LoPresto <[hidden email]>
> wrote:
>
> This schedule seems appropriate to me. Once 0.7.0 is released and we
>
> confirm
>
> the release date for 1.0, feature development is completely targeted to
>
> 1.0,
>
> correct? Security and data loss bug fixes would still be backported, but
>
> new
>
> features would not.
>
> Andy LoPresto
> [hidden email]
> [hidden email]
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On May 17, 2016, at 1:19 PM, Joe Witt <[hidden email]> wrote:
>
> Ok - i'm good with an 0.7 release too and think it is a good idea.  I
> am happy to RM the release.
>
> I'd like to select a date at which we're happy to call the 0.x line
> then feature complete which means 0.7 would be the last feature
> bearing 0.x release and from then on it would be bug fixes only
> consistent withe support model.  To do that I think we should feel
> reasonably confident that the 1.x release is close.  So let's say we
> did an 0.7 release early June - say first week of June.  I'd like us
> to say then that 1.x is targeted to early July.
>
> If this seems like a reasonable path I'll start filling out the
> tragically never updated roadmap wiki page [1] with the 0.7 target,
> 1.x target, and put some placeholder/tentatives for the 1.1 and beyond
> targets.  Will wait for additional inputs.
>
> [1]
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=58851850
>
>
> Thanks
> Joe
>
> On Tue, May 17, 2016 at 4:15 PM, Oleg Zhurakousky
> <[hidden email]> wrote:
>
> Agreed! I would like to see 0.7 within 2-3 weeks as there are a lot of
> improvements and new features/components in it already, and would like to
> give it some miles before 1.0.
>
> Oleg
>
> On May 17, 2016, at 4:02 PM, James Wing <[hidden email]> wrote:
>
> I'm definitely in favor of releasing 0.7.0, but I don't think we need be
> rigid about the schedule.  If delaying 0.7.0 a few weeks (2-4?) helps
>
> pace
>
> us towards a 1.0 in mid- to late-Summer, that seems reasonable to me.  Do
> we believe that is still a likely target?
>
> Thanks,
>
> James
>
> On Tue, May 17, 2016 at 7:30 AM, Joe Witt <[hidden email]> wrote:
>
> Team,
>
> Want to start zeroing in on the details of the next releases.  We had
> a good set of discussions around this back in January and have since
> been executing along this general path [1].
>
> On the 0.x line the next release would be 0.7.0.  There does appear to
> be a lot of useful improvements/features/fixes there now and it is
> time to do a release according to our general 6-8 week approach.
> However, given all the effort going into 1.x I'd like to get a sense
> of what the community preference is.
>
> On the 1.0 line the release is coming into focus.  Some things have
> moved into 1.x and some things look like they'd slide to the right of
> 1.x as is to be expected.  For example distributed durability (HA
> Data) looks like a good thing to do post 1.0 given the substantive
> changes present from the new HA clustering approach and multi-tenant
> authorization.  I'd also like to dive in and liberally apply Apache
> Yetus annotations [2] to all the things so we can be really explicit
> about what parts we can more freely evolve going forward.  We've been
> a bit awkwardly hamstrung thus far without these so they should help
> greatly to better convey intent.
>
> For those really interested in things coming in the 1.0 release please
> take a look through the JIRAs currently there and provide comments on
> what is important to you, what you'd like to see moved out, in, etc..
> [3].  At this point there are still a lot of things which will likely
> need to move out to allow the release to occur in a timely fashion.
>
> Also, keep in mind our stated release line/support model as found here
>
> [4].
>
>
> [1]
>
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201601.mbox/%3CCALJK9a4dMw9PyrrihpPwM7DH3R_4v8b%3Dr--LDhK7y5scob-0og%40mail.gmail.com%3E
>
>
> [2]
>
> https://yetus.apache.org/documentation/0.2.1/audience-annotations-apidocs/
>
>
> [3]
>
> https://issues.apache.org/jira/browse/NIFI-1887?jql=fixVersion%20%3D%201.0.0%20AND%20project%20%3D%20NIFI
>
>
> [4]
>
> https://cwiki.apache.org/confluence/display/NIFI/Git+Branching+and+Release+Line+Management
>
>
> Thanks
> Joe
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0

Ryan Hendrickson
I'm looking forward to 0.7.. Plenty of awesome features, like SSL with the
AMQP processors (https://issues.apache.org/jira/browse/NIFI-1521)

Thanks!

On Thu, May 26, 2016 at 7:52 AM, Joe Witt <[hidden email]> wrote:

> Ok just to wrap up this thread. Will push a couple efforts
> 1) Will start pulling together an 0.7 release
> 2) Will update the roadmap slide to put in tentative timing/major
> elements in the roadmap on the wiki page
>
> And as for whether 0.7 ends up being the last release of the 0.x line
> will just depend on 1.0 release timing and community interest in doing
> an 0.8.  We don't have to decide that now.
>
> Thanks
> Joe
>
> On Tue, May 17, 2016 at 7:12 PM, Andy LoPresto <[hidden email]>
> wrote:
> > I think Mike’s read on the published guidelines is correct, but I agree
> with
> > Joe that if we release 0.7 two weeks before 1.0, feature development
> that is
> > merged after 0.7 does not need to be backported. Maybe this is something
> we
> > should clarify on the wiki once we reach a consensus.
> >
> >
> > Andy LoPresto
> > [hidden email]
> > [hidden email]
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >
> > On May 17, 2016, at 3:43 PM, Joe Witt <[hidden email]> wrote:
> >
> > Mike
> >
> > I agree with the letter of the reading so this thread is to discuss
> > the spirit of it and how to best apply it to our situation and
> > community now.  Whether it is 'just before' or 'just after' or 'same
> > time' I think it is within the intent.  I just want us to be clear
> > what it is.  It is extra work to ensure each PR is applied to both
> > lines and extra work increases contributor and reviewer burden so we
> > should be mindful of that as it is a dragging force.  We also need to
> > keep in mind that with 1.x we have Java 8 as a minimum and so there
> > are cases which will not apply to both and we don't want folks to
> > avoid using Java 8 features just so it can apply to both.
> >
> > My preference is that we have 0.7 as the last planned feature release
> > in 0.x and with that in mind we need to choose to have it be a bit
> > before, a bit after, or at the same time as the 1.x release.  I
> > personally am comfortable with what I proposed for 0.7 vs 1.0 timing
> > but I am fine if the consensus is to release the last 0.x and 1.0 at
> > the same time.  Just hoping to avoid needing to have another feature
> > release on 0.x after 0.7 other than some special request that might
> > come up later (which is also discussed in the support doc).
> >
> > I also agree the release process for 1.0 will be significant as it
> > will include important new features.  Definitely need folks testing
> > out and providing feedback on the features early and often.
> >
> > Thanks
> > Joe
> >
> > On Tue, May 17, 2016 at 6:20 PM, Michael Moser <[hidden email]>
> wrote:
> >
> > The way I read the release support document, I don't think the feature
> > cut-off for the 0.x branch happens when we confirm a release date for
> 1.0,
> > I think it occurs once we actually release 1.0.  Maybe the cut-off can
> > happen once we declare the first 1.0 release candidate.  I'm sure we will
> > spend significant time doing testing and bug fixes on 1.0 release
> > candidates.  If I recall, we spent 2 weeks on 0.6.1 release candidates.
> >
> > -- Mike
> >
> >
> > On Tue, May 17, 2016 at 6:04 PM, Joe Witt <[hidden email]> wrote:
> >
> > I believe that is right Andy.  The support guide articulates that we
> > could do a feature release upon request if there was some specific
> > need a community member had but that otherwise the only releases on an
> > older line still supported would be focused on security/data loss type
> > items.
> >
> > Thanks
> > Joe
> >
> > On Tue, May 17, 2016 at 4:58 PM, Andy LoPresto <[hidden email]>
> > wrote:
> >
> > This schedule seems appropriate to me. Once 0.7.0 is released and we
> >
> > confirm
> >
> > the release date for 1.0, feature development is completely targeted to
> >
> > 1.0,
> >
> > correct? Security and data loss bug fixes would still be backported, but
> >
> > new
> >
> > features would not.
> >
> > Andy LoPresto
> > [hidden email]
> > [hidden email]
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >
> > On May 17, 2016, at 1:19 PM, Joe Witt <[hidden email]> wrote:
> >
> > Ok - i'm good with an 0.7 release too and think it is a good idea.  I
> > am happy to RM the release.
> >
> > I'd like to select a date at which we're happy to call the 0.x line
> > then feature complete which means 0.7 would be the last feature
> > bearing 0.x release and from then on it would be bug fixes only
> > consistent withe support model.  To do that I think we should feel
> > reasonably confident that the 1.x release is close.  So let's say we
> > did an 0.7 release early June - say first week of June.  I'd like us
> > to say then that 1.x is targeted to early July.
> >
> > If this seems like a reasonable path I'll start filling out the
> > tragically never updated roadmap wiki page [1] with the 0.7 target,
> > 1.x target, and put some placeholder/tentatives for the 1.1 and beyond
> > targets.  Will wait for additional inputs.
> >
> > [1]
> >
> >
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=58851850
> >
> >
> > Thanks
> > Joe
> >
> > On Tue, May 17, 2016 at 4:15 PM, Oleg Zhurakousky
> > <[hidden email]> wrote:
> >
> > Agreed! I would like to see 0.7 within 2-3 weeks as there are a lot of
> > improvements and new features/components in it already, and would like to
> > give it some miles before 1.0.
> >
> > Oleg
> >
> > On May 17, 2016, at 4:02 PM, James Wing <[hidden email]> wrote:
> >
> > I'm definitely in favor of releasing 0.7.0, but I don't think we need be
> > rigid about the schedule.  If delaying 0.7.0 a few weeks (2-4?) helps
> >
> > pace
> >
> > us towards a 1.0 in mid- to late-Summer, that seems reasonable to me.  Do
> > we believe that is still a likely target?
> >
> > Thanks,
> >
> > James
> >
> > On Tue, May 17, 2016 at 7:30 AM, Joe Witt <[hidden email]> wrote:
> >
> > Team,
> >
> > Want to start zeroing in on the details of the next releases.  We had
> > a good set of discussions around this back in January and have since
> > been executing along this general path [1].
> >
> > On the 0.x line the next release would be 0.7.0.  There does appear to
> > be a lot of useful improvements/features/fixes there now and it is
> > time to do a release according to our general 6-8 week approach.
> > However, given all the effort going into 1.x I'd like to get a sense
> > of what the community preference is.
> >
> > On the 1.0 line the release is coming into focus.  Some things have
> > moved into 1.x and some things look like they'd slide to the right of
> > 1.x as is to be expected.  For example distributed durability (HA
> > Data) looks like a good thing to do post 1.0 given the substantive
> > changes present from the new HA clustering approach and multi-tenant
> > authorization.  I'd also like to dive in and liberally apply Apache
> > Yetus annotations [2] to all the things so we can be really explicit
> > about what parts we can more freely evolve going forward.  We've been
> > a bit awkwardly hamstrung thus far without these so they should help
> > greatly to better convey intent.
> >
> > For those really interested in things coming in the 1.0 release please
> > take a look through the JIRAs currently there and provide comments on
> > what is important to you, what you'd like to see moved out, in, etc..
> > [3].  At this point there are still a lot of things which will likely
> > need to move out to allow the release to occur in a timely fashion.
> >
> > Also, keep in mind our stated release line/support model as found here
> >
> > [4].
> >
> >
> > [1]
> >
> >
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201601.mbox/%3CCALJK9a4dMw9PyrrihpPwM7DH3R_4v8b%3Dr--LDhK7y5scob-0og%40mail.gmail.com%3E
> >
> >
> > [2]
> >
> >
> https://yetus.apache.org/documentation/0.2.1/audience-annotations-apidocs/
> >
> >
> > [3]
> >
> >
> https://issues.apache.org/jira/browse/NIFI-1887?jql=fixVersion%20%3D%201.0.0%20AND%20project%20%3D%20NIFI
> >
> >
> > [4]
> >
> >
> https://cwiki.apache.org/confluence/display/NIFI/Git+Branching+and+Release+Line+Management
> >
> >
> > Thanks
> > Joe
> >
> >
> >
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0

Ryan Hendrickson
Also looking forward to using the TransformJSON processor:
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TransformJSON.java

Nice choice with JOLT there.

We're doing a custom one for jolt transformers for that now.

Ryan

On Fri, May 27, 2016 at 11:21 AM, Ryan H <[hidden email]>
wrote:

> I'm looking forward to 0.7.. Plenty of awesome features, like SSL with the
> AMQP processors (https://issues.apache.org/jira/browse/NIFI-1521)
>
> Thanks!
>
> On Thu, May 26, 2016 at 7:52 AM, Joe Witt <[hidden email]> wrote:
>
>> Ok just to wrap up this thread. Will push a couple efforts
>> 1) Will start pulling together an 0.7 release
>> 2) Will update the roadmap slide to put in tentative timing/major
>> elements in the roadmap on the wiki page
>>
>> And as for whether 0.7 ends up being the last release of the 0.x line
>> will just depend on 1.0 release timing and community interest in doing
>> an 0.8.  We don't have to decide that now.
>>
>> Thanks
>> Joe
>>
>> On Tue, May 17, 2016 at 7:12 PM, Andy LoPresto <[hidden email]>
>> wrote:
>> > I think Mike’s read on the published guidelines is correct, but I agree
>> with
>> > Joe that if we release 0.7 two weeks before 1.0, feature development
>> that is
>> > merged after 0.7 does not need to be backported. Maybe this is
>> something we
>> > should clarify on the wiki once we reach a consensus.
>> >
>> >
>> > Andy LoPresto
>> > [hidden email]
>> > [hidden email]
>> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>> >
>> > On May 17, 2016, at 3:43 PM, Joe Witt <[hidden email]> wrote:
>> >
>> > Mike
>> >
>> > I agree with the letter of the reading so this thread is to discuss
>> > the spirit of it and how to best apply it to our situation and
>> > community now.  Whether it is 'just before' or 'just after' or 'same
>> > time' I think it is within the intent.  I just want us to be clear
>> > what it is.  It is extra work to ensure each PR is applied to both
>> > lines and extra work increases contributor and reviewer burden so we
>> > should be mindful of that as it is a dragging force.  We also need to
>> > keep in mind that with 1.x we have Java 8 as a minimum and so there
>> > are cases which will not apply to both and we don't want folks to
>> > avoid using Java 8 features just so it can apply to both.
>> >
>> > My preference is that we have 0.7 as the last planned feature release
>> > in 0.x and with that in mind we need to choose to have it be a bit
>> > before, a bit after, or at the same time as the 1.x release.  I
>> > personally am comfortable with what I proposed for 0.7 vs 1.0 timing
>> > but I am fine if the consensus is to release the last 0.x and 1.0 at
>> > the same time.  Just hoping to avoid needing to have another feature
>> > release on 0.x after 0.7 other than some special request that might
>> > come up later (which is also discussed in the support doc).
>> >
>> > I also agree the release process for 1.0 will be significant as it
>> > will include important new features.  Definitely need folks testing
>> > out and providing feedback on the features early and often.
>> >
>> > Thanks
>> > Joe
>> >
>> > On Tue, May 17, 2016 at 6:20 PM, Michael Moser <[hidden email]>
>> wrote:
>> >
>> > The way I read the release support document, I don't think the feature
>> > cut-off for the 0.x branch happens when we confirm a release date for
>> 1.0,
>> > I think it occurs once we actually release 1.0.  Maybe the cut-off can
>> > happen once we declare the first 1.0 release candidate.  I'm sure we
>> will
>> > spend significant time doing testing and bug fixes on 1.0 release
>> > candidates.  If I recall, we spent 2 weeks on 0.6.1 release candidates.
>> >
>> > -- Mike
>> >
>> >
>> > On Tue, May 17, 2016 at 6:04 PM, Joe Witt <[hidden email]> wrote:
>> >
>> > I believe that is right Andy.  The support guide articulates that we
>> > could do a feature release upon request if there was some specific
>> > need a community member had but that otherwise the only releases on an
>> > older line still supported would be focused on security/data loss type
>> > items.
>> >
>> > Thanks
>> > Joe
>> >
>> > On Tue, May 17, 2016 at 4:58 PM, Andy LoPresto <[hidden email]>
>> > wrote:
>> >
>> > This schedule seems appropriate to me. Once 0.7.0 is released and we
>> >
>> > confirm
>> >
>> > the release date for 1.0, feature development is completely targeted to
>> >
>> > 1.0,
>> >
>> > correct? Security and data loss bug fixes would still be backported, but
>> >
>> > new
>> >
>> > features would not.
>> >
>> > Andy LoPresto
>> > [hidden email]
>> > [hidden email]
>> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>> >
>> > On May 17, 2016, at 1:19 PM, Joe Witt <[hidden email]> wrote:
>> >
>> > Ok - i'm good with an 0.7 release too and think it is a good idea.  I
>> > am happy to RM the release.
>> >
>> > I'd like to select a date at which we're happy to call the 0.x line
>> > then feature complete which means 0.7 would be the last feature
>> > bearing 0.x release and from then on it would be bug fixes only
>> > consistent withe support model.  To do that I think we should feel
>> > reasonably confident that the 1.x release is close.  So let's say we
>> > did an 0.7 release early June - say first week of June.  I'd like us
>> > to say then that 1.x is targeted to early July.
>> >
>> > If this seems like a reasonable path I'll start filling out the
>> > tragically never updated roadmap wiki page [1] with the 0.7 target,
>> > 1.x target, and put some placeholder/tentatives for the 1.1 and beyond
>> > targets.  Will wait for additional inputs.
>> >
>> > [1]
>> >
>> >
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=58851850
>> >
>> >
>> > Thanks
>> > Joe
>> >
>> > On Tue, May 17, 2016 at 4:15 PM, Oleg Zhurakousky
>> > <[hidden email]> wrote:
>> >
>> > Agreed! I would like to see 0.7 within 2-3 weeks as there are a lot of
>> > improvements and new features/components in it already, and would like
>> to
>> > give it some miles before 1.0.
>> >
>> > Oleg
>> >
>> > On May 17, 2016, at 4:02 PM, James Wing <[hidden email]> wrote:
>> >
>> > I'm definitely in favor of releasing 0.7.0, but I don't think we need be
>> > rigid about the schedule.  If delaying 0.7.0 a few weeks (2-4?) helps
>> >
>> > pace
>> >
>> > us towards a 1.0 in mid- to late-Summer, that seems reasonable to me.
>> Do
>> > we believe that is still a likely target?
>> >
>> > Thanks,
>> >
>> > James
>> >
>> > On Tue, May 17, 2016 at 7:30 AM, Joe Witt <[hidden email]> wrote:
>> >
>> > Team,
>> >
>> > Want to start zeroing in on the details of the next releases.  We had
>> > a good set of discussions around this back in January and have since
>> > been executing along this general path [1].
>> >
>> > On the 0.x line the next release would be 0.7.0.  There does appear to
>> > be a lot of useful improvements/features/fixes there now and it is
>> > time to do a release according to our general 6-8 week approach.
>> > However, given all the effort going into 1.x I'd like to get a sense
>> > of what the community preference is.
>> >
>> > On the 1.0 line the release is coming into focus.  Some things have
>> > moved into 1.x and some things look like they'd slide to the right of
>> > 1.x as is to be expected.  For example distributed durability (HA
>> > Data) looks like a good thing to do post 1.0 given the substantive
>> > changes present from the new HA clustering approach and multi-tenant
>> > authorization.  I'd also like to dive in and liberally apply Apache
>> > Yetus annotations [2] to all the things so we can be really explicit
>> > about what parts we can more freely evolve going forward.  We've been
>> > a bit awkwardly hamstrung thus far without these so they should help
>> > greatly to better convey intent.
>> >
>> > For those really interested in things coming in the 1.0 release please
>> > take a look through the JIRAs currently there and provide comments on
>> > what is important to you, what you'd like to see moved out, in, etc..
>> > [3].  At this point there are still a lot of things which will likely
>> > need to move out to allow the release to occur in a timely fashion.
>> >
>> > Also, keep in mind our stated release line/support model as found here
>> >
>> > [4].
>> >
>> >
>> > [1]
>> >
>> >
>> http://mail-archives.apache.org/mod_mbox/nifi-dev/201601.mbox/%3CCALJK9a4dMw9PyrrihpPwM7DH3R_4v8b%3Dr--LDhK7y5scob-0og%40mail.gmail.com%3E
>> >
>> >
>> > [2]
>> >
>> >
>> https://yetus.apache.org/documentation/0.2.1/audience-annotations-apidocs/
>> >
>> >
>> > [3]
>> >
>> >
>> https://issues.apache.org/jira/browse/NIFI-1887?jql=fixVersion%20%3D%201.0.0%20AND%20project%20%3D%20NIFI
>> >
>> >
>> > [4]
>> >
>> >
>> https://cwiki.apache.org/confluence/display/NIFI/Git+Branching+and+Release+Line+Management
>> >
>> >
>> > Thanks
>> > Joe
>> >
>> >
>> >
>> >
>> >
>>
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0

Joe Witt
I'll take release manager duties for 0.7.0 unless someone else with
committer status really wants to give it a go.

Right now there are 43 tickets assigned to it.  I'll go through and
punt ones on there that seem stalled or deferrable.  Of course, if
there are any that are particularly important to something you might
need please do comment to that effect.  As we close down on number of
0.7 tickets I'll kick off the proceedings.

https://issues.apache.org/jira/browse/NIFI/fixforversion/12335078

Thanks
Joe

On Tue, May 31, 2016 at 10:00 PM, Ryan H <[hidden email]> wrote:

> Also looking forward to using the TransformJSON processor:
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TransformJSON.java
>
> Nice choice with JOLT there.
>
> We're doing a custom one for jolt transformers for that now.
>
> Ryan
>
> On Fri, May 27, 2016 at 11:21 AM, Ryan H <[hidden email]>
> wrote:
>
>> I'm looking forward to 0.7.. Plenty of awesome features, like SSL with the
>> AMQP processors (https://issues.apache.org/jira/browse/NIFI-1521)
>>
>> Thanks!
>>
>> On Thu, May 26, 2016 at 7:52 AM, Joe Witt <[hidden email]> wrote:
>>
>>> Ok just to wrap up this thread. Will push a couple efforts
>>> 1) Will start pulling together an 0.7 release
>>> 2) Will update the roadmap slide to put in tentative timing/major
>>> elements in the roadmap on the wiki page
>>>
>>> And as for whether 0.7 ends up being the last release of the 0.x line
>>> will just depend on 1.0 release timing and community interest in doing
>>> an 0.8.  We don't have to decide that now.
>>>
>>> Thanks
>>> Joe
>>>
>>> On Tue, May 17, 2016 at 7:12 PM, Andy LoPresto <[hidden email]>
>>> wrote:
>>> > I think Mike’s read on the published guidelines is correct, but I agree
>>> with
>>> > Joe that if we release 0.7 two weeks before 1.0, feature development
>>> that is
>>> > merged after 0.7 does not need to be backported. Maybe this is
>>> something we
>>> > should clarify on the wiki once we reach a consensus.
>>> >
>>> >
>>> > Andy LoPresto
>>> > [hidden email]
>>> > [hidden email]
>>> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>> >
>>> > On May 17, 2016, at 3:43 PM, Joe Witt <[hidden email]> wrote:
>>> >
>>> > Mike
>>> >
>>> > I agree with the letter of the reading so this thread is to discuss
>>> > the spirit of it and how to best apply it to our situation and
>>> > community now.  Whether it is 'just before' or 'just after' or 'same
>>> > time' I think it is within the intent.  I just want us to be clear
>>> > what it is.  It is extra work to ensure each PR is applied to both
>>> > lines and extra work increases contributor and reviewer burden so we
>>> > should be mindful of that as it is a dragging force.  We also need to
>>> > keep in mind that with 1.x we have Java 8 as a minimum and so there
>>> > are cases which will not apply to both and we don't want folks to
>>> > avoid using Java 8 features just so it can apply to both.
>>> >
>>> > My preference is that we have 0.7 as the last planned feature release
>>> > in 0.x and with that in mind we need to choose to have it be a bit
>>> > before, a bit after, or at the same time as the 1.x release.  I
>>> > personally am comfortable with what I proposed for 0.7 vs 1.0 timing
>>> > but I am fine if the consensus is to release the last 0.x and 1.0 at
>>> > the same time.  Just hoping to avoid needing to have another feature
>>> > release on 0.x after 0.7 other than some special request that might
>>> > come up later (which is also discussed in the support doc).
>>> >
>>> > I also agree the release process for 1.0 will be significant as it
>>> > will include important new features.  Definitely need folks testing
>>> > out and providing feedback on the features early and often.
>>> >
>>> > Thanks
>>> > Joe
>>> >
>>> > On Tue, May 17, 2016 at 6:20 PM, Michael Moser <[hidden email]>
>>> wrote:
>>> >
>>> > The way I read the release support document, I don't think the feature
>>> > cut-off for the 0.x branch happens when we confirm a release date for
>>> 1.0,
>>> > I think it occurs once we actually release 1.0.  Maybe the cut-off can
>>> > happen once we declare the first 1.0 release candidate.  I'm sure we
>>> will
>>> > spend significant time doing testing and bug fixes on 1.0 release
>>> > candidates.  If I recall, we spent 2 weeks on 0.6.1 release candidates.
>>> >
>>> > -- Mike
>>> >
>>> >
>>> > On Tue, May 17, 2016 at 6:04 PM, Joe Witt <[hidden email]> wrote:
>>> >
>>> > I believe that is right Andy.  The support guide articulates that we
>>> > could do a feature release upon request if there was some specific
>>> > need a community member had but that otherwise the only releases on an
>>> > older line still supported would be focused on security/data loss type
>>> > items.
>>> >
>>> > Thanks
>>> > Joe
>>> >
>>> > On Tue, May 17, 2016 at 4:58 PM, Andy LoPresto <[hidden email]>
>>> > wrote:
>>> >
>>> > This schedule seems appropriate to me. Once 0.7.0 is released and we
>>> >
>>> > confirm
>>> >
>>> > the release date for 1.0, feature development is completely targeted to
>>> >
>>> > 1.0,
>>> >
>>> > correct? Security and data loss bug fixes would still be backported, but
>>> >
>>> > new
>>> >
>>> > features would not.
>>> >
>>> > Andy LoPresto
>>> > [hidden email]
>>> > [hidden email]
>>> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>> >
>>> > On May 17, 2016, at 1:19 PM, Joe Witt <[hidden email]> wrote:
>>> >
>>> > Ok - i'm good with an 0.7 release too and think it is a good idea.  I
>>> > am happy to RM the release.
>>> >
>>> > I'd like to select a date at which we're happy to call the 0.x line
>>> > then feature complete which means 0.7 would be the last feature
>>> > bearing 0.x release and from then on it would be bug fixes only
>>> > consistent withe support model.  To do that I think we should feel
>>> > reasonably confident that the 1.x release is close.  So let's say we
>>> > did an 0.7 release early June - say first week of June.  I'd like us
>>> > to say then that 1.x is targeted to early July.
>>> >
>>> > If this seems like a reasonable path I'll start filling out the
>>> > tragically never updated roadmap wiki page [1] with the 0.7 target,
>>> > 1.x target, and put some placeholder/tentatives for the 1.1 and beyond
>>> > targets.  Will wait for additional inputs.
>>> >
>>> > [1]
>>> >
>>> >
>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=58851850
>>> >
>>> >
>>> > Thanks
>>> > Joe
>>> >
>>> > On Tue, May 17, 2016 at 4:15 PM, Oleg Zhurakousky
>>> > <[hidden email]> wrote:
>>> >
>>> > Agreed! I would like to see 0.7 within 2-3 weeks as there are a lot of
>>> > improvements and new features/components in it already, and would like
>>> to
>>> > give it some miles before 1.0.
>>> >
>>> > Oleg
>>> >
>>> > On May 17, 2016, at 4:02 PM, James Wing <[hidden email]> wrote:
>>> >
>>> > I'm definitely in favor of releasing 0.7.0, but I don't think we need be
>>> > rigid about the schedule.  If delaying 0.7.0 a few weeks (2-4?) helps
>>> >
>>> > pace
>>> >
>>> > us towards a 1.0 in mid- to late-Summer, that seems reasonable to me.
>>> Do
>>> > we believe that is still a likely target?
>>> >
>>> > Thanks,
>>> >
>>> > James
>>> >
>>> > On Tue, May 17, 2016 at 7:30 AM, Joe Witt <[hidden email]> wrote:
>>> >
>>> > Team,
>>> >
>>> > Want to start zeroing in on the details of the next releases.  We had
>>> > a good set of discussions around this back in January and have since
>>> > been executing along this general path [1].
>>> >
>>> > On the 0.x line the next release would be 0.7.0.  There does appear to
>>> > be a lot of useful improvements/features/fixes there now and it is
>>> > time to do a release according to our general 6-8 week approach.
>>> > However, given all the effort going into 1.x I'd like to get a sense
>>> > of what the community preference is.
>>> >
>>> > On the 1.0 line the release is coming into focus.  Some things have
>>> > moved into 1.x and some things look like they'd slide to the right of
>>> > 1.x as is to be expected.  For example distributed durability (HA
>>> > Data) looks like a good thing to do post 1.0 given the substantive
>>> > changes present from the new HA clustering approach and multi-tenant
>>> > authorization.  I'd also like to dive in and liberally apply Apache
>>> > Yetus annotations [2] to all the things so we can be really explicit
>>> > about what parts we can more freely evolve going forward.  We've been
>>> > a bit awkwardly hamstrung thus far without these so they should help
>>> > greatly to better convey intent.
>>> >
>>> > For those really interested in things coming in the 1.0 release please
>>> > take a look through the JIRAs currently there and provide comments on
>>> > what is important to you, what you'd like to see moved out, in, etc..
>>> > [3].  At this point there are still a lot of things which will likely
>>> > need to move out to allow the release to occur in a timely fashion.
>>> >
>>> > Also, keep in mind our stated release line/support model as found here
>>> >
>>> > [4].
>>> >
>>> >
>>> > [1]
>>> >
>>> >
>>> http://mail-archives.apache.org/mod_mbox/nifi-dev/201601.mbox/%3CCALJK9a4dMw9PyrrihpPwM7DH3R_4v8b%3Dr--LDhK7y5scob-0og%40mail.gmail.com%3E
>>> >
>>> >
>>> > [2]
>>> >
>>> >
>>> https://yetus.apache.org/documentation/0.2.1/audience-annotations-apidocs/
>>> >
>>> >
>>> > [3]
>>> >
>>> >
>>> https://issues.apache.org/jira/browse/NIFI-1887?jql=fixVersion%20%3D%201.0.0%20AND%20project%20%3D%20NIFI
>>> >
>>> >
>>> > [4]
>>> >
>>> >
>>> https://cwiki.apache.org/confluence/display/NIFI/Git+Branching+and+Release+Line+Management
>>> >
>>> >
>>> > Thanks
>>> > Joe
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0

Edgardo Vega
What ever happened to the following from the 6-12 month roadmap that was
posted a while ago?

Deterministic Template Export
    https://issues.apache.org/jira/browse/NIFI-826

On Tue, May 31, 2016 at 10:07 PM, Joe Witt <[hidden email]> wrote:

> I'll take release manager duties for 0.7.0 unless someone else with
> committer status really wants to give it a go.
>
> Right now there are 43 tickets assigned to it.  I'll go through and
> punt ones on there that seem stalled or deferrable.  Of course, if
> there are any that are particularly important to something you might
> need please do comment to that effect.  As we close down on number of
> 0.7 tickets I'll kick off the proceedings.
>
> https://issues.apache.org/jira/browse/NIFI/fixforversion/12335078
>
> Thanks
> Joe
>
> On Tue, May 31, 2016 at 10:00 PM, Ryan H <[hidden email]>
> wrote:
> > Also looking forward to using the TransformJSON processor:
> >
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TransformJSON.java
> >
> > Nice choice with JOLT there.
> >
> > We're doing a custom one for jolt transformers for that now.
> >
> > Ryan
> >
> > On Fri, May 27, 2016 at 11:21 AM, Ryan H <[hidden email]>
> > wrote:
> >
> >> I'm looking forward to 0.7.. Plenty of awesome features, like SSL with
> the
> >> AMQP processors (https://issues.apache.org/jira/browse/NIFI-1521)
> >>
> >> Thanks!
> >>
> >> On Thu, May 26, 2016 at 7:52 AM, Joe Witt <[hidden email]> wrote:
> >>
> >>> Ok just to wrap up this thread. Will push a couple efforts
> >>> 1) Will start pulling together an 0.7 release
> >>> 2) Will update the roadmap slide to put in tentative timing/major
> >>> elements in the roadmap on the wiki page
> >>>
> >>> And as for whether 0.7 ends up being the last release of the 0.x line
> >>> will just depend on 1.0 release timing and community interest in doing
> >>> an 0.8.  We don't have to decide that now.
> >>>
> >>> Thanks
> >>> Joe
> >>>
> >>> On Tue, May 17, 2016 at 7:12 PM, Andy LoPresto <[hidden email]>
> >>> wrote:
> >>> > I think Mike’s read on the published guidelines is correct, but I
> agree
> >>> with
> >>> > Joe that if we release 0.7 two weeks before 1.0, feature development
> >>> that is
> >>> > merged after 0.7 does not need to be backported. Maybe this is
> >>> something we
> >>> > should clarify on the wiki once we reach a consensus.
> >>> >
> >>> >
> >>> > Andy LoPresto
> >>> > [hidden email]
> >>> > [hidden email]
> >>> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >>> >
> >>> > On May 17, 2016, at 3:43 PM, Joe Witt <[hidden email]> wrote:
> >>> >
> >>> > Mike
> >>> >
> >>> > I agree with the letter of the reading so this thread is to discuss
> >>> > the spirit of it and how to best apply it to our situation and
> >>> > community now.  Whether it is 'just before' or 'just after' or 'same
> >>> > time' I think it is within the intent.  I just want us to be clear
> >>> > what it is.  It is extra work to ensure each PR is applied to both
> >>> > lines and extra work increases contributor and reviewer burden so we
> >>> > should be mindful of that as it is a dragging force.  We also need to
> >>> > keep in mind that with 1.x we have Java 8 as a minimum and so there
> >>> > are cases which will not apply to both and we don't want folks to
> >>> > avoid using Java 8 features just so it can apply to both.
> >>> >
> >>> > My preference is that we have 0.7 as the last planned feature release
> >>> > in 0.x and with that in mind we need to choose to have it be a bit
> >>> > before, a bit after, or at the same time as the 1.x release.  I
> >>> > personally am comfortable with what I proposed for 0.7 vs 1.0 timing
> >>> > but I am fine if the consensus is to release the last 0.x and 1.0 at
> >>> > the same time.  Just hoping to avoid needing to have another feature
> >>> > release on 0.x after 0.7 other than some special request that might
> >>> > come up later (which is also discussed in the support doc).
> >>> >
> >>> > I also agree the release process for 1.0 will be significant as it
> >>> > will include important new features.  Definitely need folks testing
> >>> > out and providing feedback on the features early and often.
> >>> >
> >>> > Thanks
> >>> > Joe
> >>> >
> >>> > On Tue, May 17, 2016 at 6:20 PM, Michael Moser <[hidden email]>
> >>> wrote:
> >>> >
> >>> > The way I read the release support document, I don't think the
> feature
> >>> > cut-off for the 0.x branch happens when we confirm a release date for
> >>> 1.0,
> >>> > I think it occurs once we actually release 1.0.  Maybe the cut-off
> can
> >>> > happen once we declare the first 1.0 release candidate.  I'm sure we
> >>> will
> >>> > spend significant time doing testing and bug fixes on 1.0 release
> >>> > candidates.  If I recall, we spent 2 weeks on 0.6.1 release
> candidates.
> >>> >
> >>> > -- Mike
> >>> >
> >>> >
> >>> > On Tue, May 17, 2016 at 6:04 PM, Joe Witt <[hidden email]>
> wrote:
> >>> >
> >>> > I believe that is right Andy.  The support guide articulates that we
> >>> > could do a feature release upon request if there was some specific
> >>> > need a community member had but that otherwise the only releases on
> an
> >>> > older line still supported would be focused on security/data loss
> type
> >>> > items.
> >>> >
> >>> > Thanks
> >>> > Joe
> >>> >
> >>> > On Tue, May 17, 2016 at 4:58 PM, Andy LoPresto <[hidden email]
> >
> >>> > wrote:
> >>> >
> >>> > This schedule seems appropriate to me. Once 0.7.0 is released and we
> >>> >
> >>> > confirm
> >>> >
> >>> > the release date for 1.0, feature development is completely targeted
> to
> >>> >
> >>> > 1.0,
> >>> >
> >>> > correct? Security and data loss bug fixes would still be backported,
> but
> >>> >
> >>> > new
> >>> >
> >>> > features would not.
> >>> >
> >>> > Andy LoPresto
> >>> > [hidden email]
> >>> > [hidden email]
> >>> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >>> >
> >>> > On May 17, 2016, at 1:19 PM, Joe Witt <[hidden email]> wrote:
> >>> >
> >>> > Ok - i'm good with an 0.7 release too and think it is a good idea.  I
> >>> > am happy to RM the release.
> >>> >
> >>> > I'd like to select a date at which we're happy to call the 0.x line
> >>> > then feature complete which means 0.7 would be the last feature
> >>> > bearing 0.x release and from then on it would be bug fixes only
> >>> > consistent withe support model.  To do that I think we should feel
> >>> > reasonably confident that the 1.x release is close.  So let's say we
> >>> > did an 0.7 release early June - say first week of June.  I'd like us
> >>> > to say then that 1.x is targeted to early July.
> >>> >
> >>> > If this seems like a reasonable path I'll start filling out the
> >>> > tragically never updated roadmap wiki page [1] with the 0.7 target,
> >>> > 1.x target, and put some placeholder/tentatives for the 1.1 and
> beyond
> >>> > targets.  Will wait for additional inputs.
> >>> >
> >>> > [1]
> >>> >
> >>> >
> >>>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=58851850
> >>> >
> >>> >
> >>> > Thanks
> >>> > Joe
> >>> >
> >>> > On Tue, May 17, 2016 at 4:15 PM, Oleg Zhurakousky
> >>> > <[hidden email]> wrote:
> >>> >
> >>> > Agreed! I would like to see 0.7 within 2-3 weeks as there are a lot
> of
> >>> > improvements and new features/components in it already, and would
> like
> >>> to
> >>> > give it some miles before 1.0.
> >>> >
> >>> > Oleg
> >>> >
> >>> > On May 17, 2016, at 4:02 PM, James Wing <[hidden email]> wrote:
> >>> >
> >>> > I'm definitely in favor of releasing 0.7.0, but I don't think we
> need be
> >>> > rigid about the schedule.  If delaying 0.7.0 a few weeks (2-4?) helps
> >>> >
> >>> > pace
> >>> >
> >>> > us towards a 1.0 in mid- to late-Summer, that seems reasonable to me.
> >>> Do
> >>> > we believe that is still a likely target?
> >>> >
> >>> > Thanks,
> >>> >
> >>> > James
> >>> >
> >>> > On Tue, May 17, 2016 at 7:30 AM, Joe Witt <[hidden email]>
> wrote:
> >>> >
> >>> > Team,
> >>> >
> >>> > Want to start zeroing in on the details of the next releases.  We had
> >>> > a good set of discussions around this back in January and have since
> >>> > been executing along this general path [1].
> >>> >
> >>> > On the 0.x line the next release would be 0.7.0.  There does appear
> to
> >>> > be a lot of useful improvements/features/fixes there now and it is
> >>> > time to do a release according to our general 6-8 week approach.
> >>> > However, given all the effort going into 1.x I'd like to get a sense
> >>> > of what the community preference is.
> >>> >
> >>> > On the 1.0 line the release is coming into focus.  Some things have
> >>> > moved into 1.x and some things look like they'd slide to the right of
> >>> > 1.x as is to be expected.  For example distributed durability (HA
> >>> > Data) looks like a good thing to do post 1.0 given the substantive
> >>> > changes present from the new HA clustering approach and multi-tenant
> >>> > authorization.  I'd also like to dive in and liberally apply Apache
> >>> > Yetus annotations [2] to all the things so we can be really explicit
> >>> > about what parts we can more freely evolve going forward.  We've been
> >>> > a bit awkwardly hamstrung thus far without these so they should help
> >>> > greatly to better convey intent.
> >>> >
> >>> > For those really interested in things coming in the 1.0 release
> please
> >>> > take a look through the JIRAs currently there and provide comments on
> >>> > what is important to you, what you'd like to see moved out, in, etc..
> >>> > [3].  At this point there are still a lot of things which will likely
> >>> > need to move out to allow the release to occur in a timely fashion.
> >>> >
> >>> > Also, keep in mind our stated release line/support model as found
> here
> >>> >
> >>> > [4].
> >>> >
> >>> >
> >>> > [1]
> >>> >
> >>> >
> >>>
> http://mail-archives.apache.org/mod_mbox/nifi-dev/201601.mbox/%3CCALJK9a4dMw9PyrrihpPwM7DH3R_4v8b%3Dr--LDhK7y5scob-0og%40mail.gmail.com%3E
> >>> >
> >>> >
> >>> > [2]
> >>> >
> >>> >
> >>>
> https://yetus.apache.org/documentation/0.2.1/audience-annotations-apidocs/
> >>> >
> >>> >
> >>> > [3]
> >>> >
> >>> >
> >>>
> https://issues.apache.org/jira/browse/NIFI-1887?jql=fixVersion%20%3D%201.0.0%20AND%20project%20%3D%20NIFI
> >>> >
> >>> >
> >>> > [4]
> >>> >
> >>> >
> >>>
> https://cwiki.apache.org/confluence/display/NIFI/Git+Branching+and+Release+Line+Management
> >>> >
> >>> >
> >>> > Thanks
> >>> > Joe
> >>> >
> >>> >
> >>> >
> >>> >
> >>> >
> >>>
> >>
> >>
>



--
Cheers,

Edgardo
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0

Joe Witt
I had an off-list conversation with OlegZ about this recently and he
said he planned on trying to tackle this for 1.x timing.  Oleg - you
have any updates you can share on the JIRA?

It is definitely an important item for those that want to do effective
CM which is diff friendly.  Is just a step of many we should take to
make the whole dev/ops lifecycle for a flow as good as possible.

On Wed, Jun 1, 2016 at 8:28 AM, Edgardo Vega <[hidden email]> wrote:

> What ever happened to the following from the 6-12 month roadmap that was
> posted a while ago?
>
> Deterministic Template Export
>     https://issues.apache.org/jira/browse/NIFI-826
>
> On Tue, May 31, 2016 at 10:07 PM, Joe Witt <[hidden email]> wrote:
>
>> I'll take release manager duties for 0.7.0 unless someone else with
>> committer status really wants to give it a go.
>>
>> Right now there are 43 tickets assigned to it.  I'll go through and
>> punt ones on there that seem stalled or deferrable.  Of course, if
>> there are any that are particularly important to something you might
>> need please do comment to that effect.  As we close down on number of
>> 0.7 tickets I'll kick off the proceedings.
>>
>> https://issues.apache.org/jira/browse/NIFI/fixforversion/12335078
>>
>> Thanks
>> Joe
>>
>> On Tue, May 31, 2016 at 10:00 PM, Ryan H <[hidden email]>
>> wrote:
>> > Also looking forward to using the TransformJSON processor:
>> >
>> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TransformJSON.java
>> >
>> > Nice choice with JOLT there.
>> >
>> > We're doing a custom one for jolt transformers for that now.
>> >
>> > Ryan
>> >
>> > On Fri, May 27, 2016 at 11:21 AM, Ryan H <[hidden email]>
>> > wrote:
>> >
>> >> I'm looking forward to 0.7.. Plenty of awesome features, like SSL with
>> the
>> >> AMQP processors (https://issues.apache.org/jira/browse/NIFI-1521)
>> >>
>> >> Thanks!
>> >>
>> >> On Thu, May 26, 2016 at 7:52 AM, Joe Witt <[hidden email]> wrote:
>> >>
>> >>> Ok just to wrap up this thread. Will push a couple efforts
>> >>> 1) Will start pulling together an 0.7 release
>> >>> 2) Will update the roadmap slide to put in tentative timing/major
>> >>> elements in the roadmap on the wiki page
>> >>>
>> >>> And as for whether 0.7 ends up being the last release of the 0.x line
>> >>> will just depend on 1.0 release timing and community interest in doing
>> >>> an 0.8.  We don't have to decide that now.
>> >>>
>> >>> Thanks
>> >>> Joe
>> >>>
>> >>> On Tue, May 17, 2016 at 7:12 PM, Andy LoPresto <[hidden email]>
>> >>> wrote:
>> >>> > I think Mike’s read on the published guidelines is correct, but I
>> agree
>> >>> with
>> >>> > Joe that if we release 0.7 two weeks before 1.0, feature development
>> >>> that is
>> >>> > merged after 0.7 does not need to be backported. Maybe this is
>> >>> something we
>> >>> > should clarify on the wiki once we reach a consensus.
>> >>> >
>> >>> >
>> >>> > Andy LoPresto
>> >>> > [hidden email]
>> >>> > [hidden email]
>> >>> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>> >>> >
>> >>> > On May 17, 2016, at 3:43 PM, Joe Witt <[hidden email]> wrote:
>> >>> >
>> >>> > Mike
>> >>> >
>> >>> > I agree with the letter of the reading so this thread is to discuss
>> >>> > the spirit of it and how to best apply it to our situation and
>> >>> > community now.  Whether it is 'just before' or 'just after' or 'same
>> >>> > time' I think it is within the intent.  I just want us to be clear
>> >>> > what it is.  It is extra work to ensure each PR is applied to both
>> >>> > lines and extra work increases contributor and reviewer burden so we
>> >>> > should be mindful of that as it is a dragging force.  We also need to
>> >>> > keep in mind that with 1.x we have Java 8 as a minimum and so there
>> >>> > are cases which will not apply to both and we don't want folks to
>> >>> > avoid using Java 8 features just so it can apply to both.
>> >>> >
>> >>> > My preference is that we have 0.7 as the last planned feature release
>> >>> > in 0.x and with that in mind we need to choose to have it be a bit
>> >>> > before, a bit after, or at the same time as the 1.x release.  I
>> >>> > personally am comfortable with what I proposed for 0.7 vs 1.0 timing
>> >>> > but I am fine if the consensus is to release the last 0.x and 1.0 at
>> >>> > the same time.  Just hoping to avoid needing to have another feature
>> >>> > release on 0.x after 0.7 other than some special request that might
>> >>> > come up later (which is also discussed in the support doc).
>> >>> >
>> >>> > I also agree the release process for 1.0 will be significant as it
>> >>> > will include important new features.  Definitely need folks testing
>> >>> > out and providing feedback on the features early and often.
>> >>> >
>> >>> > Thanks
>> >>> > Joe
>> >>> >
>> >>> > On Tue, May 17, 2016 at 6:20 PM, Michael Moser <[hidden email]>
>> >>> wrote:
>> >>> >
>> >>> > The way I read the release support document, I don't think the
>> feature
>> >>> > cut-off for the 0.x branch happens when we confirm a release date for
>> >>> 1.0,
>> >>> > I think it occurs once we actually release 1.0.  Maybe the cut-off
>> can
>> >>> > happen once we declare the first 1.0 release candidate.  I'm sure we
>> >>> will
>> >>> > spend significant time doing testing and bug fixes on 1.0 release
>> >>> > candidates.  If I recall, we spent 2 weeks on 0.6.1 release
>> candidates.
>> >>> >
>> >>> > -- Mike
>> >>> >
>> >>> >
>> >>> > On Tue, May 17, 2016 at 6:04 PM, Joe Witt <[hidden email]>
>> wrote:
>> >>> >
>> >>> > I believe that is right Andy.  The support guide articulates that we
>> >>> > could do a feature release upon request if there was some specific
>> >>> > need a community member had but that otherwise the only releases on
>> an
>> >>> > older line still supported would be focused on security/data loss
>> type
>> >>> > items.
>> >>> >
>> >>> > Thanks
>> >>> > Joe
>> >>> >
>> >>> > On Tue, May 17, 2016 at 4:58 PM, Andy LoPresto <[hidden email]
>> >
>> >>> > wrote:
>> >>> >
>> >>> > This schedule seems appropriate to me. Once 0.7.0 is released and we
>> >>> >
>> >>> > confirm
>> >>> >
>> >>> > the release date for 1.0, feature development is completely targeted
>> to
>> >>> >
>> >>> > 1.0,
>> >>> >
>> >>> > correct? Security and data loss bug fixes would still be backported,
>> but
>> >>> >
>> >>> > new
>> >>> >
>> >>> > features would not.
>> >>> >
>> >>> > Andy LoPresto
>> >>> > [hidden email]
>> >>> > [hidden email]
>> >>> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>> >>> >
>> >>> > On May 17, 2016, at 1:19 PM, Joe Witt <[hidden email]> wrote:
>> >>> >
>> >>> > Ok - i'm good with an 0.7 release too and think it is a good idea.  I
>> >>> > am happy to RM the release.
>> >>> >
>> >>> > I'd like to select a date at which we're happy to call the 0.x line
>> >>> > then feature complete which means 0.7 would be the last feature
>> >>> > bearing 0.x release and from then on it would be bug fixes only
>> >>> > consistent withe support model.  To do that I think we should feel
>> >>> > reasonably confident that the 1.x release is close.  So let's say we
>> >>> > did an 0.7 release early June - say first week of June.  I'd like us
>> >>> > to say then that 1.x is targeted to early July.
>> >>> >
>> >>> > If this seems like a reasonable path I'll start filling out the
>> >>> > tragically never updated roadmap wiki page [1] with the 0.7 target,
>> >>> > 1.x target, and put some placeholder/tentatives for the 1.1 and
>> beyond
>> >>> > targets.  Will wait for additional inputs.
>> >>> >
>> >>> > [1]
>> >>> >
>> >>> >
>> >>>
>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=58851850
>> >>> >
>> >>> >
>> >>> > Thanks
>> >>> > Joe
>> >>> >
>> >>> > On Tue, May 17, 2016 at 4:15 PM, Oleg Zhurakousky
>> >>> > <[hidden email]> wrote:
>> >>> >
>> >>> > Agreed! I would like to see 0.7 within 2-3 weeks as there are a lot
>> of
>> >>> > improvements and new features/components in it already, and would
>> like
>> >>> to
>> >>> > give it some miles before 1.0.
>> >>> >
>> >>> > Oleg
>> >>> >
>> >>> > On May 17, 2016, at 4:02 PM, James Wing <[hidden email]> wrote:
>> >>> >
>> >>> > I'm definitely in favor of releasing 0.7.0, but I don't think we
>> need be
>> >>> > rigid about the schedule.  If delaying 0.7.0 a few weeks (2-4?) helps
>> >>> >
>> >>> > pace
>> >>> >
>> >>> > us towards a 1.0 in mid- to late-Summer, that seems reasonable to me.
>> >>> Do
>> >>> > we believe that is still a likely target?
>> >>> >
>> >>> > Thanks,
>> >>> >
>> >>> > James
>> >>> >
>> >>> > On Tue, May 17, 2016 at 7:30 AM, Joe Witt <[hidden email]>
>> wrote:
>> >>> >
>> >>> > Team,
>> >>> >
>> >>> > Want to start zeroing in on the details of the next releases.  We had
>> >>> > a good set of discussions around this back in January and have since
>> >>> > been executing along this general path [1].
>> >>> >
>> >>> > On the 0.x line the next release would be 0.7.0.  There does appear
>> to
>> >>> > be a lot of useful improvements/features/fixes there now and it is
>> >>> > time to do a release according to our general 6-8 week approach.
>> >>> > However, given all the effort going into 1.x I'd like to get a sense
>> >>> > of what the community preference is.
>> >>> >
>> >>> > On the 1.0 line the release is coming into focus.  Some things have
>> >>> > moved into 1.x and some things look like they'd slide to the right of
>> >>> > 1.x as is to be expected.  For example distributed durability (HA
>> >>> > Data) looks like a good thing to do post 1.0 given the substantive
>> >>> > changes present from the new HA clustering approach and multi-tenant
>> >>> > authorization.  I'd also like to dive in and liberally apply Apache
>> >>> > Yetus annotations [2] to all the things so we can be really explicit
>> >>> > about what parts we can more freely evolve going forward.  We've been
>> >>> > a bit awkwardly hamstrung thus far without these so they should help
>> >>> > greatly to better convey intent.
>> >>> >
>> >>> > For those really interested in things coming in the 1.0 release
>> please
>> >>> > take a look through the JIRAs currently there and provide comments on
>> >>> > what is important to you, what you'd like to see moved out, in, etc..
>> >>> > [3].  At this point there are still a lot of things which will likely
>> >>> > need to move out to allow the release to occur in a timely fashion.
>> >>> >
>> >>> > Also, keep in mind our stated release line/support model as found
>> here
>> >>> >
>> >>> > [4].
>> >>> >
>> >>> >
>> >>> > [1]
>> >>> >
>> >>> >
>> >>>
>> http://mail-archives.apache.org/mod_mbox/nifi-dev/201601.mbox/%3CCALJK9a4dMw9PyrrihpPwM7DH3R_4v8b%3Dr--LDhK7y5scob-0og%40mail.gmail.com%3E
>> >>> >
>> >>> >
>> >>> > [2]
>> >>> >
>> >>> >
>> >>>
>> https://yetus.apache.org/documentation/0.2.1/audience-annotations-apidocs/
>> >>> >
>> >>> >
>> >>> > [3]
>> >>> >
>> >>> >
>> >>>
>> https://issues.apache.org/jira/browse/NIFI-1887?jql=fixVersion%20%3D%201.0.0%20AND%20project%20%3D%20NIFI
>> >>> >
>> >>> >
>> >>> > [4]
>> >>> >
>> >>> >
>> >>>
>> https://cwiki.apache.org/confluence/display/NIFI/Git+Branching+and+Release+Line+Management
>> >>> >
>> >>> >
>> >>> > Thanks
>> >>> > Joe
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>> >
>> >>>
>> >>
>> >>
>>
>
>
>
> --
> Cheers,
>
> Edgardo
Reply | Threaded
Open this post in threaded view
|

Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0

Oleg Zhurakousky
Yes, it's on my list for 1.0

Oleg

> On Jun 1, 2016, at 08:33, Joe Witt <[hidden email]> wrote:
>
> I had an off-list conversation with OlegZ about this recently and he
> said he planned on trying to tackle this for 1.x timing.  Oleg - you
> have any updates you can share on the JIRA?
>
> It is definitely an important item for those that want to do effective
> CM which is diff friendly.  Is just a step of many we should take to
> make the whole dev/ops lifecycle for a flow as good as possible.
>
>> On Wed, Jun 1, 2016 at 8:28 AM, Edgardo Vega <[hidden email]> wrote:
>> What ever happened to the following from the 6-12 month roadmap that was
>> posted a while ago?
>>
>> Deterministic Template Export
>>    https://issues.apache.org/jira/browse/NIFI-826
>>
>>> On Tue, May 31, 2016 at 10:07 PM, Joe Witt <[hidden email]> wrote:
>>>
>>> I'll take release manager duties for 0.7.0 unless someone else with
>>> committer status really wants to give it a go.
>>>
>>> Right now there are 43 tickets assigned to it.  I'll go through and
>>> punt ones on there that seem stalled or deferrable.  Of course, if
>>> there are any that are particularly important to something you might
>>> need please do comment to that effect.  As we close down on number of
>>> 0.7 tickets I'll kick off the proceedings.
>>>
>>> https://issues.apache.org/jira/browse/NIFI/fixforversion/12335078
>>>
>>> Thanks
>>> Joe
>>>
>>> On Tue, May 31, 2016 at 10:00 PM, Ryan H <[hidden email]>
>>> wrote:
>>>> Also looking forward to using the TransformJSON processor:
>>> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TransformJSON.java
>>>>
>>>> Nice choice with JOLT there.
>>>>
>>>> We're doing a custom one for jolt transformers for that now.
>>>>
>>>> Ryan
>>>>
>>>> On Fri, May 27, 2016 at 11:21 AM, Ryan H <[hidden email]>
>>>> wrote:
>>>>
>>>>> I'm looking forward to 0.7.. Plenty of awesome features, like SSL with
>>> the
>>>>> AMQP processors (https://issues.apache.org/jira/browse/NIFI-1521)
>>>>>
>>>>> Thanks!
>>>>>
>>>>>> On Thu, May 26, 2016 at 7:52 AM, Joe Witt <[hidden email]> wrote:
>>>>>>
>>>>>> Ok just to wrap up this thread. Will push a couple efforts
>>>>>> 1) Will start pulling together an 0.7 release
>>>>>> 2) Will update the roadmap slide to put in tentative timing/major
>>>>>> elements in the roadmap on the wiki page
>>>>>>
>>>>>> And as for whether 0.7 ends up being the last release of the 0.x line
>>>>>> will just depend on 1.0 release timing and community interest in doing
>>>>>> an 0.8.  We don't have to decide that now.
>>>>>>
>>>>>> Thanks
>>>>>> Joe
>>>>>>
>>>>>> On Tue, May 17, 2016 at 7:12 PM, Andy LoPresto <[hidden email]>
>>>>>> wrote:
>>>>>>> I think Mike’s read on the published guidelines is correct, but I
>>> agree
>>>>>> with
>>>>>>> Joe that if we release 0.7 two weeks before 1.0, feature development
>>>>>> that is
>>>>>>> merged after 0.7 does not need to be backported. Maybe this is
>>>>>> something we
>>>>>>> should clarify on the wiki once we reach a consensus.
>>>>>>>
>>>>>>>
>>>>>>> Andy LoPresto
>>>>>>> [hidden email]
>>>>>>> [hidden email]
>>>>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>>>>>>
>>>>>>> On May 17, 2016, at 3:43 PM, Joe Witt <[hidden email]> wrote:
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>>> I agree with the letter of the reading so this thread is to discuss
>>>>>>> the spirit of it and how to best apply it to our situation and
>>>>>>> community now.  Whether it is 'just before' or 'just after' or 'same
>>>>>>> time' I think it is within the intent.  I just want us to be clear
>>>>>>> what it is.  It is extra work to ensure each PR is applied to both
>>>>>>> lines and extra work increases contributor and reviewer burden so we
>>>>>>> should be mindful of that as it is a dragging force.  We also need to
>>>>>>> keep in mind that with 1.x we have Java 8 as a minimum and so there
>>>>>>> are cases which will not apply to both and we don't want folks to
>>>>>>> avoid using Java 8 features just so it can apply to both.
>>>>>>>
>>>>>>> My preference is that we have 0.7 as the last planned feature release
>>>>>>> in 0.x and with that in mind we need to choose to have it be a bit
>>>>>>> before, a bit after, or at the same time as the 1.x release.  I
>>>>>>> personally am comfortable with what I proposed for 0.7 vs 1.0 timing
>>>>>>> but I am fine if the consensus is to release the last 0.x and 1.0 at
>>>>>>> the same time.  Just hoping to avoid needing to have another feature
>>>>>>> release on 0.x after 0.7 other than some special request that might
>>>>>>> come up later (which is also discussed in the support doc).
>>>>>>>
>>>>>>> I also agree the release process for 1.0 will be significant as it
>>>>>>> will include important new features.  Definitely need folks testing
>>>>>>> out and providing feedback on the features early and often.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Joe
>>>>>>>
>>>>>>>> On Tue, May 17, 2016 at 6:20 PM, Michael Moser <[hidden email]>
>>>>>>> wrote:
>>>>>>>
>>>>>>> The way I read the release support document, I don't think the
>>> feature
>>>>>>> cut-off for the 0.x branch happens when we confirm a release date for
>>>>>> 1.0,
>>>>>>> I think it occurs once we actually release 1.0.  Maybe the cut-off
>>> can
>>>>>>> happen once we declare the first 1.0 release candidate.  I'm sure we
>>>>>> will
>>>>>>> spend significant time doing testing and bug fixes on 1.0 release
>>>>>>> candidates.  If I recall, we spent 2 weeks on 0.6.1 release
>>> candidates.
>>>>>>>
>>>>>>> -- Mike
>>>>>>>
>>>>>>>
>>>>>>> On Tue, May 17, 2016 at 6:04 PM, Joe Witt <[hidden email]>
>>> wrote:
>>>>>>>
>>>>>>> I believe that is right Andy.  The support guide articulates that we
>>>>>>> could do a feature release upon request if there was some specific
>>>>>>> need a community member had but that otherwise the only releases on
>>> an
>>>>>>> older line still supported would be focused on security/data loss
>>> type
>>>>>>> items.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Joe
>>>>>>>
>>>>>>> On Tue, May 17, 2016 at 4:58 PM, Andy LoPresto <[hidden email]
>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> This schedule seems appropriate to me. Once 0.7.0 is released and we
>>>>>>>
>>>>>>> confirm
>>>>>>>
>>>>>>> the release date for 1.0, feature development is completely targeted
>>> to
>>>>>>>
>>>>>>> 1.0,
>>>>>>>
>>>>>>> correct? Security and data loss bug fixes would still be backported,
>>> but
>>>>>>>
>>>>>>> new
>>>>>>>
>>>>>>> features would not.
>>>>>>>
>>>>>>> Andy LoPresto
>>>>>>> [hidden email]
>>>>>>> [hidden email]
>>>>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>>>>>>
>>>>>>> On May 17, 2016, at 1:19 PM, Joe Witt <[hidden email]> wrote:
>>>>>>>
>>>>>>> Ok - i'm good with an 0.7 release too and think it is a good idea.  I
>>>>>>> am happy to RM the release.
>>>>>>>
>>>>>>> I'd like to select a date at which we're happy to call the 0.x line
>>>>>>> then feature complete which means 0.7 would be the last feature
>>>>>>> bearing 0.x release and from then on it would be bug fixes only
>>>>>>> consistent withe support model.  To do that I think we should feel
>>>>>>> reasonably confident that the 1.x release is close.  So let's say we
>>>>>>> did an 0.7 release early June - say first week of June.  I'd like us
>>>>>>> to say then that 1.x is targeted to early July.
>>>>>>>
>>>>>>> If this seems like a reasonable path I'll start filling out the
>>>>>>> tragically never updated roadmap wiki page [1] with the 0.7 target,
>>>>>>> 1.x target, and put some placeholder/tentatives for the 1.1 and
>>> beyond
>>>>>>> targets.  Will wait for additional inputs.
>>>>>>>
>>>>>>> [1]
>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=58851850
>>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>> Joe
>>>>>>>
>>>>>>> On Tue, May 17, 2016 at 4:15 PM, Oleg Zhurakousky
>>>>>>> <[hidden email]> wrote:
>>>>>>>
>>>>>>> Agreed! I would like to see 0.7 within 2-3 weeks as there are a lot
>>> of
>>>>>>> improvements and new features/components in it already, and would
>>> like
>>>>>> to
>>>>>>> give it some miles before 1.0.
>>>>>>>
>>>>>>> Oleg
>>>>>>>
>>>>>>> On May 17, 2016, at 4:02 PM, James Wing <[hidden email]> wrote:
>>>>>>>
>>>>>>> I'm definitely in favor of releasing 0.7.0, but I don't think we
>>> need be
>>>>>>> rigid about the schedule.  If delaying 0.7.0 a few weeks (2-4?) helps
>>>>>>>
>>>>>>> pace
>>>>>>>
>>>>>>> us towards a 1.0 in mid- to late-Summer, that seems reasonable to me.
>>>>>> Do
>>>>>>> we believe that is still a likely target?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> James
>>>>>>>
>>>>>>> On Tue, May 17, 2016 at 7:30 AM, Joe Witt <[hidden email]>
>>> wrote:
>>>>>>>
>>>>>>> Team,
>>>>>>>
>>>>>>> Want to start zeroing in on the details of the next releases.  We had
>>>>>>> a good set of discussions around this back in January and have since
>>>>>>> been executing along this general path [1].
>>>>>>>
>>>>>>> On the 0.x line the next release would be 0.7.0.  There does appear
>>> to
>>>>>>> be a lot of useful improvements/features/fixes there now and it is
>>>>>>> time to do a release according to our general 6-8 week approach.
>>>>>>> However, given all the effort going into 1.x I'd like to get a sense
>>>>>>> of what the community preference is.
>>>>>>>
>>>>>>> On the 1.0 line the release is coming into focus.  Some things have
>>>>>>> moved into 1.x and some things look like they'd slide to the right of
>>>>>>> 1.x as is to be expected.  For example distributed durability (HA
>>>>>>> Data) looks like a good thing to do post 1.0 given the substantive
>>>>>>> changes present from the new HA clustering approach and multi-tenant
>>>>>>> authorization.  I'd also like to dive in and liberally apply Apache
>>>>>>> Yetus annotations [2] to all the things so we can be really explicit
>>>>>>> about what parts we can more freely evolve going forward.  We've been
>>>>>>> a bit awkwardly hamstrung thus far without these so they should help
>>>>>>> greatly to better convey intent.
>>>>>>>
>>>>>>> For those really interested in things coming in the 1.0 release
>>> please
>>>>>>> take a look through the JIRAs currently there and provide comments on
>>>>>>> what is important to you, what you'd like to see moved out, in, etc..
>>>>>>> [3].  At this point there are still a lot of things which will likely
>>>>>>> need to move out to allow the release to occur in a timely fashion.
>>>>>>>
>>>>>>> Also, keep in mind our stated release line/support model as found
>>> here
>>>>>>>
>>>>>>> [4].
>>>>>>>
>>>>>>>
>>>>>>> [1]
>>> http://mail-archives.apache.org/mod_mbox/nifi-dev/201601.mbox/%3CCALJK9a4dMw9PyrrihpPwM7DH3R_4v8b%3Dr--LDhK7y5scob-0og%40mail.gmail.com%3E
>>>>>>>
>>>>>>>
>>>>>>> [2]
>>> https://yetus.apache.org/documentation/0.2.1/audience-annotations-apidocs/
>>>>>>>
>>>>>>>
>>>>>>> [3]
>>> https://issues.apache.org/jira/browse/NIFI-1887?jql=fixVersion%20%3D%201.0.0%20AND%20project%20%3D%20NIFI
>>>>>>>
>>>>>>>
>>>>>>> [4]
>>> https://cwiki.apache.org/confluence/display/NIFI/Git+Branching+and+Release+Line+Management
>>>>>>>
>>>>>>>
>>>>>>> Thanks
>>>>>>> Joe
>>
>>
>>
>> --
>> Cheers,
>>
>> Edgardo
>