Re: [discuss] should we do a nifi 1.7.1 release?

[Andy LoPresto]

I did not look for all bugs patched since 1.7.0 was released; I was just 
replying to people who had commented on this thread explicitly asking for 
certain things. I do not intend to pull in any commits other than what was 
explicitly requested.

Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Jul 9, 2018, at 6:38 PM, Matt Burgess  wrote:
> 
> This Jira search [1] for Bugs resolved in 1.8.0 has 10 items, there
> are some I don't see in this list (NIFI-5278 [2] and NIFI-5349 [3]),
> should these all be included or on a case-by-case basis?
> 
> Thanks,
> Matt
> 
> [1] 
> https://issues.apache.org/jira/browse/NIFI-5394?jql=project%20%3D%20NIFI%20AND%20fixVersion%20%3D%201.8.0%20and%20Type%20%3D%20Bug%20and%20resolution%20%3D%20Fixed
> [2] https://issues.apache.org/jira/browse/NIFI-5278
> [3] https://issues.apache.org/jira/browse/NIFI-5349
> On Mon, Jul 9, 2018 at 9:11 PM Andy LoPresto  wrote:
>> 
>> To clarify for everyone posting on this thread, 0.0.x releases are bug fix 
>> releases only, and cannot introduce new features. We will release a 1.7.1 
>> version with the fix for NIFI-5370 (wildcard certificate issue in secure 
>> cluster) but this release will not contain any new feature work. Currently, 
>> I have slated for it:
>> 
>> * NIFI-5370 wildcard cert fix <- not yet merged; needs +1
>> * NIFI-5377 stack overflow with circular reference <- not yet merged; needs 
>> +1
>> * NIFI-5316 bug in FetchParquet
>> * NIFI-5361 processors with active threads do not run on restart
>> * NIFI-5362 suppress error message on successful processor termination
>> 
>> Not addressed:
>> 
>> * NIFI-5331 poisoned journal requires restart <- no work done on this that I 
>> see
>> * NIFI-5368 transitive controller services not validated by mock runner <- 
>> no work done on this that I see
>> * Docker improvements
>> * NIFI-5334 GetMongo passing NiFi flowfile attributes
>> 
>> 
>> Andy LoPresto
>> alopre...@apache.org
>> alopresto.apa...@gmail.com
>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>> 
>> On Jul 9, 2018, at 12:21 PM, Ryan Hendrickson 
>>  wrote:
>> 
>> Ahh gotcha, and good point on grabbing the master.  I may do that...
>> 
>> Thanks,
>> Ryan
>> 
>> On Mon, Jul 9, 2018 at 3:18 PM Andy LoPresto  wrote:
>> 
>> Hi Ryan,
>> 
>> That sounds like a separate discussion the community should weigh in on.
>> Right now, the release management process is fairly extensive and takes a
>> few days of manual work to perform. In addition, releases need to be voted
>> on by the community in order to be released, so this is an effort for
>> community members as well.
>> 
>> I’m not opposed to improving our RM process to make this work easier, but
>> it’s not as simple as just cutting a release more frequently at this point
>> in time. If you so desire, you can always checkout the current master or
>> specific feature branches. It’s possible we could do something like a
>> nightly tag, but officially releasing that through the Apache process is
>> probably not doable in the near-term.
>> 
>> The semantic versioning is also an issue, because 1.6.x releases are
>> supposed to be bug fixes only, not feature releases [1].
>> 
>> For the public API the Apache NiFi project aims to follow versioning
>> principles as described at Semantic Versioning 2.0.0 
>> 
>> Consider the following scenarios in the context of the most recent
>> 'example' release being 0.0.1 and with the understanding that these are
>> about the public API as defined above.
>> 
>>  - For releases which are comprised solely of bug fixes or non-feature
>>  introducing or enhancing changes that requires only a 'patch' version bump
>>  (the Z part in X.Y.Z).  So the next release then is 0.0.2.
>>  - For releases which include backward compatible changes to introduce
>>  feature enhancements or new features that requires a 'minor' version change
>>  and the 'patch' version resets to '0' (the Y part in X.Y.0).  So the next
>>  release then is 0.1.0. A 'minor' version change is also required for any
>>  change that could result in an existing flow becoming invalid, such as the
>>  addition of a required property with no default or the addition of a
>>  relationship, or the removal of a property or relationship. Note: it is
>>  *NOT* acceptable in a 'minor' version to change anything that can
>>  result in an existing flow behaving differently (other than a component
>>  becoming invalid). Doing so would fundamentally alter the way in which
>>  organizations process data without them realizing it.
>>  - For releases which include non-backward compatible changes or
>>  changes deemed so substantive by the community that it is considered a
>>  'major' version change and the minor and patch versions reset to '0' (the X
>>  part in X.0.0).  So the next release then is 1.0.0.
>> 
>> After a release occurs the 'patch' version will be automatically adjust

Re: [discuss] should we do a nifi 1.7.1 release?

[Matt Burgess]

This Jira search [1] for Bugs resolved in 1.8.0 has 10 items, there
are some I don't see in this list (NIFI-5278 [2] and NIFI-5349 [3]),
should these all be included or on a case-by-case basis?

Thanks,
Matt

[1] 
https://issues.apache.org/jira/browse/NIFI-5394?jql=project%20%3D%20NIFI%20AND%20fixVersion%20%3D%201.8.0%20and%20Type%20%3D%20Bug%20and%20resolution%20%3D%20Fixed
[2] https://issues.apache.org/jira/browse/NIFI-5278
[3] https://issues.apache.org/jira/browse/NIFI-5349
On Mon, Jul 9, 2018 at 9:11 PM Andy LoPresto  wrote:
>
> To clarify for everyone posting on this thread, 0.0.x releases are bug fix 
> releases only, and cannot introduce new features. We will release a 1.7.1 
> version with the fix for NIFI-5370 (wildcard certificate issue in secure 
> cluster) but this release will not contain any new feature work. Currently, I 
> have slated for it:
>
> * NIFI-5370 wildcard cert fix <- not yet merged; needs +1
> * NIFI-5377 stack overflow with circular reference <- not yet merged; needs +1
> * NIFI-5316 bug in FetchParquet
> * NIFI-5361 processors with active threads do not run on restart
> * NIFI-5362 suppress error message on successful processor termination
>
> Not addressed:
>
> * NIFI-5331 poisoned journal requires restart <- no work done on this that I 
> see
> * NIFI-5368 transitive controller services not validated by mock runner <- no 
> work done on this that I see
> * Docker improvements
> * NIFI-5334 GetMongo passing NiFi flowfile attributes
>
>
> Andy LoPresto
> alopre...@apache.org
> alopresto.apa...@gmail.com
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Jul 9, 2018, at 12:21 PM, Ryan Hendrickson 
>  wrote:
>
> Ahh gotcha, and good point on grabbing the master.  I may do that...
>
> Thanks,
> Ryan
>
> On Mon, Jul 9, 2018 at 3:18 PM Andy LoPresto  wrote:
>
> Hi Ryan,
>
> That sounds like a separate discussion the community should weigh in on.
> Right now, the release management process is fairly extensive and takes a
> few days of manual work to perform. In addition, releases need to be voted
> on by the community in order to be released, so this is an effort for
> community members as well.
>
> I’m not opposed to improving our RM process to make this work easier, but
> it’s not as simple as just cutting a release more frequently at this point
> in time. If you so desire, you can always checkout the current master or
> specific feature branches. It’s possible we could do something like a
> nightly tag, but officially releasing that through the Apache process is
> probably not doable in the near-term.
>
> The semantic versioning is also an issue, because 1.6.x releases are
> supposed to be bug fixes only, not feature releases [1].
>
> For the public API the Apache NiFi project aims to follow versioning
> principles as described at Semantic Versioning 2.0.0 
>
> Consider the following scenarios in the context of the most recent
> 'example' release being 0.0.1 and with the understanding that these are
> about the public API as defined above.
>
>   - For releases which are comprised solely of bug fixes or non-feature
>   introducing or enhancing changes that requires only a 'patch' version bump
>   (the Z part in X.Y.Z).  So the next release then is 0.0.2.
>   - For releases which include backward compatible changes to introduce
>   feature enhancements or new features that requires a 'minor' version change
>   and the 'patch' version resets to '0' (the Y part in X.Y.0).  So the next
>   release then is 0.1.0. A 'minor' version change is also required for any
>   change that could result in an existing flow becoming invalid, such as the
>   addition of a required property with no default or the addition of a
>   relationship, or the removal of a property or relationship. Note: it is
>   *NOT* acceptable in a 'minor' version to change anything that can
>   result in an existing flow behaving differently (other than a component
>   becoming invalid). Doing so would fundamentally alter the way in which
>   organizations process data without them realizing it.
>   - For releases which include non-backward compatible changes or
>   changes deemed so substantive by the community that it is considered a
>   'major' version change and the minor and patch versions reset to '0' (the X
>   part in X.0.0).  So the next release then is 1.0.0.
>
> After a release occurs the 'patch' version will be automatically adjusted
> by maven without the release manager doing anything special.  So rarely
> will this value need to be manually set.  In the event of a 'major' or
> 'minor' bump though the entire relevant source tree will need to be
> adjusted.
>
>
>
> [1]
> https://cwiki.apache.org/confluence/display/NIFI/Version+Scheme+and+API+Compatibility
>
> Andy LoPresto
> alopre...@apache.org
> *alopresto.apa...@gmail.com *
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Jul 9, 2018, at 12:11 PM, Ryan Hendrickson <
> ryan.andrew.hen

Re: [discuss] should we do a nifi 1.7.1 release?

[Andy LoPresto]

To clarify for everyone posting on this thread, 0.0.x releases are bug fix 
releases only, and cannot introduce new features. We will release a 1.7.1 
version with the fix for NIFI-5370 (wildcard certificate issue in secure 
cluster) but this release will not contain any new feature work. Currently, I 
have slated for it:

* NIFI-5370 wildcard cert fix <- not yet merged; needs +1
* NIFI-5377 stack overflow with circular reference <- not yet merged; needs +1
* NIFI-5316 bug in FetchParquet
* NIFI-5361 processors with active threads do not run on restart
* NIFI-5362 suppress error message on successful processor termination

Not addressed:

* NIFI-5331 poisoned journal requires restart <- no work done on this that I see
* NIFI-5368 transitive controller services not validated by mock runner <- no 
work done on this that I see
* Docker improvements
* NIFI-5334 GetMongo passing NiFi flowfile attributes


Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Jul 9, 2018, at 12:21 PM, Ryan Hendrickson 
>  wrote:
> 
> Ahh gotcha, and good point on grabbing the master.  I may do that...
> 
> Thanks,
> Ryan
> 
> On Mon, Jul 9, 2018 at 3:18 PM Andy LoPresto  > wrote:
> 
>> Hi Ryan,
>> 
>> That sounds like a separate discussion the community should weigh in on.
>> Right now, the release management process is fairly extensive and takes a
>> few days of manual work to perform. In addition, releases need to be voted
>> on by the community in order to be released, so this is an effort for
>> community members as well.
>> 
>> I’m not opposed to improving our RM process to make this work easier, but
>> it’s not as simple as just cutting a release more frequently at this point
>> in time. If you so desire, you can always checkout the current master or
>> specific feature branches. It’s possible we could do something like a
>> nightly tag, but officially releasing that through the Apache process is
>> probably not doable in the near-term.
>> 
>> The semantic versioning is also an issue, because 1.6.x releases are
>> supposed to be bug fixes only, not feature releases [1].
>> 
>> For the public API the Apache NiFi project aims to follow versioning
>> principles as described at Semantic Versioning 2.0.0 > >
>> 
>> Consider the following scenarios in the context of the most recent
>> 'example' release being 0.0.1 and with the understanding that these are
>> about the public API as defined above.
>> 
>>   - For releases which are comprised solely of bug fixes or non-feature
>>   introducing or enhancing changes that requires only a 'patch' version bump
>>   (the Z part in X.Y.Z).  So the next release then is 0.0.2.
>>   - For releases which include backward compatible changes to introduce
>>   feature enhancements or new features that requires a 'minor' version change
>>   and the 'patch' version resets to '0' (the Y part in X.Y.0).  So the next
>>   release then is 0.1.0. A 'minor' version change is also required for any
>>   change that could result in an existing flow becoming invalid, such as the
>>   addition of a required property with no default or the addition of a
>>   relationship, or the removal of a property or relationship. Note: it is
>>   *NOT* acceptable in a 'minor' version to change anything that can
>>   result in an existing flow behaving differently (other than a component
>>   becoming invalid). Doing so would fundamentally alter the way in which
>>   organizations process data without them realizing it.
>>   - For releases which include non-backward compatible changes or
>>   changes deemed so substantive by the community that it is considered a
>>   'major' version change and the minor and patch versions reset to '0' (the X
>>   part in X.0.0).  So the next release then is 1.0.0.
>> 
>> After a release occurs the 'patch' version will be automatically adjusted
>> by maven without the release manager doing anything special.  So rarely
>> will this value need to be manually set.  In the event of a 'major' or
>> 'minor' bump though the entire relevant source tree will need to be
>> adjusted.
>> 
>> 
>> 
>> [1]
>> https://cwiki.apache.org/confluence/display/NIFI/Version+Scheme+and+API+Compatibility
>>  
>> 
>> 
>> Andy LoPresto
>> alopre...@apache.org 
>> *alopresto.apa...@gmail.com  
>> mailto:alopresto.apa...@gmail.com>>*
>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>> 
>> On Jul 9, 2018, at 12:11 PM, Ryan Hendrickson <
>> ryan.andrew.hendrick...@gmail.com 
>> > wrote:
>> 
>> As a user of NiFi, and someone converting things to use more standard
>> processors, vs writing custom ones, I'd prefer smaller releases, or
>> possible a release that on

Re: [discuss] should we do a nifi 1.7.1 release?

[Ryan Hendrickson]

Ahh gotcha, and good point on grabbing the master.  I may do that...

Thanks,
Ryan

On Mon, Jul 9, 2018 at 3:18 PM Andy LoPresto  wrote:

> Hi Ryan,
>
> That sounds like a separate discussion the community should weigh in on.
> Right now, the release management process is fairly extensive and takes a
> few days of manual work to perform. In addition, releases need to be voted
> on by the community in order to be released, so this is an effort for
> community members as well.
>
> I’m not opposed to improving our RM process to make this work easier, but
> it’s not as simple as just cutting a release more frequently at this point
> in time. If you so desire, you can always checkout the current master or
> specific feature branches. It’s possible we could do something like a
> nightly tag, but officially releasing that through the Apache process is
> probably not doable in the near-term.
>
> The semantic versioning is also an issue, because 1.6.x releases are
> supposed to be bug fixes only, not feature releases [1].
>
> For the public API the Apache NiFi project aims to follow versioning
> principles as described at Semantic Versioning 2.0.0 
>
> Consider the following scenarios in the context of the most recent
> 'example' release being 0.0.1 and with the understanding that these are
> about the public API as defined above.
>
>- For releases which are comprised solely of bug fixes or non-feature
>introducing or enhancing changes that requires only a 'patch' version bump
>(the Z part in X.Y.Z).  So the next release then is 0.0.2.
>- For releases which include backward compatible changes to introduce
>feature enhancements or new features that requires a 'minor' version change
>and the 'patch' version resets to '0' (the Y part in X.Y.0).  So the next
>release then is 0.1.0. A 'minor' version change is also required for any
>change that could result in an existing flow becoming invalid, such as the
>addition of a required property with no default or the addition of a
>relationship, or the removal of a property or relationship. Note: it is
>*NOT* acceptable in a 'minor' version to change anything that can
>result in an existing flow behaving differently (other than a component
>becoming invalid). Doing so would fundamentally alter the way in which
>organizations process data without them realizing it.
>- For releases which include non-backward compatible changes or
>changes deemed so substantive by the community that it is considered a
>'major' version change and the minor and patch versions reset to '0' (the X
>part in X.0.0).  So the next release then is 1.0.0.
>
> After a release occurs the 'patch' version will be automatically adjusted
> by maven without the release manager doing anything special.  So rarely
> will this value need to be manually set.  In the event of a 'major' or
> 'minor' bump though the entire relevant source tree will need to be
> adjusted.
>
>
>
> [1]
> https://cwiki.apache.org/confluence/display/NIFI/Version+Scheme+and+API+Compatibility
>
> Andy LoPresto
> alopre...@apache.org
> *alopresto.apa...@gmail.com *
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Jul 9, 2018, at 12:11 PM, Ryan Hendrickson <
> ryan.andrew.hendrick...@gmail.com> wrote:
>
> As a user of NiFi, and someone converting things to use more standard
> processors, vs writing custom ones, I'd prefer smaller releases, or
> possible a release that only updates Processors with the bug fixes and
> improvements that went into them vs having to diff the configuration files
> each upgrade.  The bigger releases, like 1.6.0 (163 updates), and 1.7.0
> (191 updates) are great, but the waiting game for fixes to go into a
> release seems long.  I'd love a weekly release, or even just know that once
> a month there will be a 1.6.x release coming out with updates to
> processors.
>
> That said, I can't wait for this fix, slated for 1.8.0:
> https://issues.apache.org/jira/browse/NIFI-5334  (GetMongo should pass
> along NiFi FlowFile Attributes), love to see it in a 1.7.1.
>
> Ryan
>
> On Fri, Jul 6, 2018 at 10:55 AM Mike Thomsen 
> wrote:
>
> Aldrin and I got some Docker improvements in lately that might be good to
> throw in as well. They can definitely wait until 1.8 if everyone wants to
> KISS this release, but they could also add some real value for the docker
> users too.
>
> On Fri, Jul 6, 2018 at 1:31 AM V, Prashanth (Nokia - IN/Bangalore) <
> prashant...@nokia.com> wrote:
>
> Thanks Andy..  +1 for 1.7.1 release.
>
> Thanks & Regards,
> Prashanth
>
> From: Andy LoPresto [mailto:alopre...@apache.org ]
> Sent: Friday, July 06, 2018 1:34 AM
> To: dev@nifi.apache.org
> Subject: Re: [discuss] should we do a nifi 1.7.1 release?
>
> I’m working on the wildcard cert issue and would be able to put that
>
> along
>
> with some other minor fixes into a 1.7.1 release.
>
> Andy LoPresto
> alopre...@apache.org

Re: [discuss] should we do a nifi 1.7.1 release?

[Andy LoPresto]

Hi Ryan,

That sounds like a separate discussion the community should weigh in on. Right 
now, the release management process is fairly extensive and takes a few days of 
manual work to perform. In addition, releases need to be voted on by the 
community in order to be released, so this is an effort for community members 
as well.

I’m not opposed to improving our RM process to make this work easier, but it’s 
not as simple as just cutting a release more frequently at this point in time. 
If you so desire, you can always checkout the current master or specific 
feature branches. It’s possible we could do something like a nightly tag, but 
officially releasing that through the Apache process is probably not doable in 
the near-term.

The semantic versioning is also an issue, because 1.6.x releases are supposed 
to be bug fixes only, not feature releases [1].

> For the public API the Apache NiFi project aims to follow versioning 
> principles as described at Semantic Versioning 2.0.0 
> Consider the following scenarios in the context of the most recent 'example' 
> release being 0.0.1 and with the understanding that these are about the 
> public API as defined above.
> For releases which are comprised solely of bug fixes or non-feature 
> introducing or enhancing changes that requires only a 'patch' version bump 
> (the Z part in X.Y.Z).  So the next release then is 0.0.2.
> For releases which include backward compatible changes to introduce feature 
> enhancements or new features that requires a 'minor' version change and the 
> 'patch' version resets to '0' (the Y part in X.Y.0).  So the next release 
> then is 0.1.0. A 'minor' version change is also required for any change that 
> could result in an existing flow becoming invalid, such as the addition of a 
> required property with no default or the addition of a relationship, or the 
> removal of a property or relationship. Note: it is NOT acceptable in a 
> 'minor' version to change anything that can result in an existing flow 
> behaving differently (other than a component becoming invalid). Doing so 
> would fundamentally alter the way in which organizations process data without 
> them realizing it.
> For releases which include non-backward compatible changes or changes deemed 
> so substantive by the community that it is considered a 'major' version 
> change and the minor and patch versions reset to '0' (the X part in X.0.0).  
> So the next release then is 1.0.0.
> After a release occurs the 'patch' version will be automatically adjusted by 
> maven without the release manager doing anything special.  So rarely will 
> this value need to be manually set.  In the event of a 'major' or 'minor' 
> bump though the entire relevant source tree will need to be adjusted.


[1] 
https://cwiki.apache.org/confluence/display/NIFI/Version+Scheme+and+API+Compatibility
 


Andy LoPresto
alopre...@apache.org
alopresto.apa...@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Jul 9, 2018, at 12:11 PM, Ryan Hendrickson 
>  wrote:
> 
> As a user of NiFi, and someone converting things to use more standard
> processors, vs writing custom ones, I'd prefer smaller releases, or
> possible a release that only updates Processors with the bug fixes and
> improvements that went into them vs having to diff the configuration files
> each upgrade.  The bigger releases, like 1.6.0 (163 updates), and 1.7.0
> (191 updates) are great, but the waiting game for fixes to go into a
> release seems long.  I'd love a weekly release, or even just know that once
> a month there will be a 1.6.x release coming out with updates to processors.
> 
> That said, I can't wait for this fix, slated for 1.8.0:
> https://issues.apache.org/jira/browse/NIFI-5334  (GetMongo should pass
> along NiFi FlowFile Attributes), love to see it in a 1.7.1.
> 
> Ryan
> 
> On Fri, Jul 6, 2018 at 10:55 AM Mike Thomsen  wrote:
> 
>> Aldrin and I got some Docker improvements in lately that might be good to
>> throw in as well. They can definitely wait until 1.8 if everyone wants to
>> KISS this release, but they could also add some real value for the docker
>> users too.
>> 
>> On Fri, Jul 6, 2018 at 1:31 AM V, Prashanth (Nokia - IN/Bangalore) <
>> prashant...@nokia.com> wrote:
>> 
>>> Thanks Andy..  +1 for 1.7.1 release.
>>> 
>>> Thanks & Regards,
>>> Prashanth
>>> 
>>> From: Andy LoPresto [mailto:alopre...@apache.org]
>>> Sent: Friday, July 06, 2018 1:34 AM
>>> To: dev@nifi.apache.org
>>> Subject: Re: [discuss] should we do a nifi 1.7.1 release?
>>> 
>>> I’m working on the wildcard cert issue and would be able to put that
>> along
>>> with some other minor fixes into a 1.7.1 release.
>>> 
>>> Andy LoPresto
>>> alopre...@apache.org
>>> alopresto.apa...@gmail.com
>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6

Re: [discuss] should we do a nifi 1.7.1 release?

[Ryan Hendrickson]

As a user of NiFi, and someone converting things to use more standard
processors, vs writing custom ones, I'd prefer smaller releases, or
possible a release that only updates Processors with the bug fixes and
improvements that went into them vs having to diff the configuration files
each upgrade.  The bigger releases, like 1.6.0 (163 updates), and 1.7.0
(191 updates) are great, but the waiting game for fixes to go into a
release seems long.  I'd love a weekly release, or even just know that once
a month there will be a 1.6.x release coming out with updates to processors.

That said, I can't wait for this fix, slated for 1.8.0:
https://issues.apache.org/jira/browse/NIFI-5334  (GetMongo should pass
along NiFi FlowFile Attributes), love to see it in a 1.7.1.

Ryan

On Fri, Jul 6, 2018 at 10:55 AM Mike Thomsen  wrote:

> Aldrin and I got some Docker improvements in lately that might be good to
> throw in as well. They can definitely wait until 1.8 if everyone wants to
> KISS this release, but they could also add some real value for the docker
> users too.
>
> On Fri, Jul 6, 2018 at 1:31 AM V, Prashanth (Nokia - IN/Bangalore) <
> prashant...@nokia.com> wrote:
>
> > Thanks Andy..  +1 for 1.7.1 release.
> >
> > Thanks & Regards,
> > Prashanth
> >
> > From: Andy LoPresto [mailto:alopre...@apache.org]
> > Sent: Friday, July 06, 2018 1:34 AM
> > To: dev@nifi.apache.org
> > Subject: Re: [discuss] should we do a nifi 1.7.1 release?
> >
> > I’m working on the wildcard cert issue and would be able to put that
> along
> > with some other minor fixes into a 1.7.1 release.
> >
> > Andy LoPresto
> > alopre...@apache.org
> > alopresto.apa...@gmail.com
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >
> > On Jul 5, 2018, at 11:01 AM, Robert R. Bruno  > rbru...@gmail.com>> wrote:
> >
> > +1 as well.  Any chance of this one as well?
> >
> > https://issues.apache.org/jira/browse/NIFI-5316
> >
> > On Thu, Jul 5, 2018, 11:33 Mark Bean  > mark.o.b...@gmail.com>> wrote:
> >
> >
> > +1 for a 1.7.1 release if it contains a fix for NIFI-5368 [1]. This bug
> is
> > breaking multiple unit tests on custom processors.
> >
> > [1] https://issues.apache.org/jira/browse/NIFI-5368
> >
> >
> >
> > On Thu, Jul 5, 2018 at 12:23 PM Joe Witt  > joe.w...@gmail.com>> wrote:
> >
> >
> > team,
> >
> > Wanted to kick off a thread to suggest we do a nifi 1.7.1 release.  It
> > sounds like we might have an issue handling wildcard certs in 1.7.0
> > [1] and it was reported again in an email today i think.  Also, if
> > this one is deemed legit it seems worth sorting out [2].  I'd imagine
> > there are a few other bug fixes as well we can pull in.
> >
> >
> > [1] https://issues.apache.org/jira/browse/NIFI-5370
> > [2] https://issues.apache.org/jira/browse/NIFI-5377
> >
> > Thanks
> > Joe
> >
> >
> >
>

Register now for ApacheCon and save $250

[Rich Bowen]

Greetings, Apache software enthusiasts!

(You’re getting this because you’re on one or more dev@ or users@ lists 
for some Apache Software Foundation project.)


ApacheCon North America, in Montreal, is now just 80 days away, and 
early bird prices end in just two weeks - on July 21. Prices will be 
going up from $550 to $800 so register NOW to save $250, at 
http://apachecon.com/acna18


And don’t forget to reserve your hotel room. We have negotiated a 
special rate and the room block closes August 24. 
http://www.apachecon.com/acna18/venue.html


Our schedule includes over 100 talks and we’ll be featuring talks from 
dozens of ASF projects.,  We have inspiring keynotes from some of the 
brilliant members of our community and the wider tech space, including:


 * Myrle Krantz, PMC chair for Apache Fineract, and leader in the open 
source financing space
 * Cliff Schmidt, founder of Literacy Bridge (now Amplio) and creator 
of the Talking Book project

 * Bridget Kromhout, principal cloud developer advocate at Microsoft
 * Euan McLeod, Comcast engineer, and pioneer in streaming video

We’ll also be featuring tracks for Geospatial science, Tomcat, 
Cloudstack, and Big Data, as well as numerous other fields where Apache 
software is leading the way. See the full schedule at 
http://apachecon.com/acna18/schedule.html


As usual we’ll be running our Apache BarCamp, the traditional ApacheCon 
Hackathon, and the Wednesday evening Lighting Talks, too, so you’ll want 
to be there.


Register today at http://apachecon.com/acna18 and we’ll see you in Montreal!

--
Rich Bowen
VP, Conferences, The Apache Software Foundation
h...@apachecon.com
@ApacheCon