[discuss] should we do a nifi 1.7.1 release?

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

[discuss] should we do a nifi 1.7.1 release?

Joe Witt
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
Reply | Threaded
Open this post in threaded view
|

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

Brandon DeVries
This one may be worth fixing in 1.7.1 as well:

https://issues.apache.org/jira/browse/NIFI-5331



On Thu, Jul 5, 2018 at 12:23 PM Joe Witt <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

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

Mark Bean
In reply to this post by Joe Witt
+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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|

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

Robert R. Bruno
+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 <[hidden email]> 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 <[hidden email]> 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
> >
>
Reply | Threaded
Open this post in threaded view
|

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

Andy LoPresto-2
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
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Jul 5, 2018, at 11:01 AM, Robert R. Bruno <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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




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

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

Pierre Villard
Would be nice to also include:
https://issues.apache.org/jira/browse/NIFI-5362
https://issues.apache.org/jira/browse/NIFI-5361


2018-07-05 22:03 GMT+02:00 Andy LoPresto <[hidden email]>:

> 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
> [hidden email]
> *[hidden email] <[hidden email]>*
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Jul 5, 2018, at 11:01 AM, Robert R. Bruno <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

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

V, Prashanth (Nokia - IN/Bangalore)
In reply to this post by Andy LoPresto-2
Thanks Andy..  +1 for 1.7.1 release.

Thanks & Regards,
Prashanth

From: Andy LoPresto [mailto:[hidden email]]
Sent: Friday, July 06, 2018 1:34 AM
To: [hidden email]
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
[hidden email]<mailto:[hidden email]>
[hidden email]<mailto:[hidden email]>
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Jul 5, 2018, at 11:01 AM, Robert R. Bruno <[hidden email]<mailto:[hidden email]>> 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 <[hidden email]<mailto:[hidden email]>> 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 <[hidden email]<mailto:[hidden email]>> 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


Reply | Threaded
Open this post in threaded view
|

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

Mike Thomsen
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) <
[hidden email]> wrote:

> Thanks Andy..  +1 for 1.7.1 release.
>
> Thanks & Regards,
> Prashanth
>
> From: Andy LoPresto [mailto:[hidden email]]
> Sent: Friday, July 06, 2018 1:34 AM
> To: [hidden email]
> 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
> [hidden email]<mailto:[hidden email]>
> [hidden email]<mailto:[hidden email]>
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Jul 5, 2018, at 11:01 AM, Robert R. Bruno <[hidden email]<mailto:
> [hidden email]>> 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 <[hidden email]<mailto:
> [hidden email]>> 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 <[hidden email]<mailto:
> [hidden email]>> 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
>
>
>
Reply | Threaded
Open this post in threaded view
|

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

Ryan Hendrickson-2
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 <[hidden email]> 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) <
> [hidden email]> wrote:
>
> > Thanks Andy..  +1 for 1.7.1 release.
> >
> > Thanks & Regards,
> > Prashanth
> >
> > From: Andy LoPresto [mailto:[hidden email]]
> > Sent: Friday, July 06, 2018 1:34 AM
> > To: [hidden email]
> > 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
> > [hidden email]<mailto:[hidden email]>
> > [hidden email]<mailto:[hidden email]>
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >
> > On Jul 5, 2018, at 11:01 AM, Robert R. Bruno <[hidden email]<mailto:
> > [hidden email]>> 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 <[hidden email]<mailto:
> > [hidden email]>> 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 <[hidden email]<mailto:
> > [hidden email]>> 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
> >
> >
> >
>
Reply | Threaded
Open this post in threaded view
|

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

Andy LoPresto-2
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.  




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

On Jul 9, 2018, at 12:11 PM, Ryan Hendrickson <[hidden email]> 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 <[hidden email]> 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) <
[hidden email]> wrote:

Thanks Andy..  +1 for 1.7.1 release.

Thanks & Regards,
Prashanth

From: Andy LoPresto [[hidden email]]
Sent: Friday, July 06, 2018 1:34 AM
To: [hidden email]
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
[hidden email]<[hidden email]>
[hidden email]<[hidden email]>
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Jul 5, 2018, at 11:01 AM, Robert R. Bruno <[hidden email]<mailto:
[hidden email]>> 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 <[hidden email]<mailto:
[hidden email]>> 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 <[hidden email]<mailto:
[hidden email]>> 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






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

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

Ryan Hendrickson-2
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 <[hidden email]> 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 <http://semver.org/>
>
> 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
> [hidden email]
> *[hidden email] <[hidden email]>*
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Jul 9, 2018, at 12:11 PM, Ryan Hendrickson <
> [hidden email]> 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 <[hidden email]>
> 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) <
> [hidden email]> wrote:
>
> Thanks Andy..  +1 for 1.7.1 release.
>
> Thanks & Regards,
> Prashanth
>
> From: Andy LoPresto [mailto:[hidden email] <[hidden email]>]
> Sent: Friday, July 06, 2018 1:34 AM
> To: [hidden email]
> 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
> [hidden email]<mailto:[hidden email] <[hidden email]>>
> [hidden email]<mailto:[hidden email]
> <[hidden email]>>
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Jul 5, 2018, at 11:01 AM, Robert R. Bruno <[hidden email]<mailto:
> [hidden email]>> 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 <[hidden email]<mailto:
> [hidden email]>> 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 <[hidden email]<mailto:
> [hidden email]>> 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
>
>
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

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

Andy LoPresto-2
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
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Jul 9, 2018, at 12:21 PM, Ryan Hendrickson <[hidden email]> 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 <[hidden email]> 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 <http://semver.org/>

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
[hidden email]
*[hidden email] <[hidden email]>*
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Jul 9, 2018, at 12:11 PM, Ryan Hendrickson <
[hidden email]> 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 <[hidden email]>
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) <
[hidden email]> wrote:

Thanks Andy..  +1 for 1.7.1 release.

Thanks & Regards,
Prashanth

From: Andy LoPresto [[hidden email] <[hidden email]>]
Sent: Friday, July 06, 2018 1:34 AM
To: [hidden email]
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
[hidden email]<[hidden email] <[hidden email]>>
[hidden email]<[hidden email]
<[hidden email]>>
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Jul 5, 2018, at 11:01 AM, Robert R. Bruno <[hidden email]<mailto:
[hidden email]>> 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 <[hidden email]<mailto:
[hidden email]>> 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 <[hidden email]<mailto:
[hidden email]>> 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


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

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

Matt Burgess-2
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 <[hidden email]> 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
> [hidden email]
> [hidden email]
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Jul 9, 2018, at 12:21 PM, Ryan Hendrickson <[hidden email]> 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 <[hidden email]> 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 <http://semver.org/>
>
> 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
> [hidden email]
> *[hidden email] <[hidden email]>*
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Jul 9, 2018, at 12:11 PM, Ryan Hendrickson <
> [hidden email]> 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 <[hidden email]>
> 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) <
> [hidden email]> wrote:
>
> Thanks Andy..  +1 for 1.7.1 release.
>
> Thanks & Regards,
> Prashanth
>
> From: Andy LoPresto [mailto:[hidden email] <[hidden email]>]
> Sent: Friday, July 06, 2018 1:34 AM
> To: [hidden email]
> 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
> [hidden email]<mailto:[hidden email] <[hidden email]>>
> [hidden email]<mailto:[hidden email]
> <[hidden email]>>
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Jul 5, 2018, at 11:01 AM, Robert R. Bruno <[hidden email]<mailto:
> [hidden email]>> 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 <[hidden email]<mailto:
> [hidden email]>> 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 <[hidden email]<mailto:
> [hidden email]>> 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
>
>
Reply | Threaded
Open this post in threaded view
|

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

Andy LoPresto-2
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
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Jul 9, 2018, at 6:38 PM, Matt Burgess <[hidden email]> 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 <[hidden email]> 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
[hidden email]
[hidden email]
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Jul 9, 2018, at 12:21 PM, Ryan Hendrickson <[hidden email]> 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 <[hidden email]> 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 <http://semver.org/>

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
[hidden email]
*[hidden email] <[hidden email]>*
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Jul 9, 2018, at 12:11 PM, Ryan Hendrickson <
[hidden email]> 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 <[hidden email]>
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) <
[hidden email]> wrote:

Thanks Andy..  +1 for 1.7.1 release.

Thanks & Regards,
Prashanth

From: Andy LoPresto [mailto:[hidden email] <[hidden email]>]
Sent: Friday, July 06, 2018 1:34 AM
To: [hidden email]
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
[hidden email]<mailto:[hidden email] <[hidden email]>>
[hidden email]<mailto:[hidden email]
<[hidden email]>>
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Jul 5, 2018, at 11:01 AM, Robert R. Bruno <[hidden email]<mailto:
[hidden email]>> 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 <[hidden email]<mailto:
[hidden email]>> 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 <[hidden email]<mailto:
[hidden email]>> 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




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

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

Mark Bean
FYI - NIFI-5368 has been completed and merged to master. It should be
included in 1.7.1.

Thanks,
Mark

On Mon, Jul 9, 2018 at 9:46 PM Andy LoPresto <[hidden email]> wrote:

> 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
> [hidden email]
> *[hidden email] <[hidden email]>*
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Jul 9, 2018, at 6:38 PM, Matt Burgess <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> [hidden email]
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Jul 9, 2018, at 12:21 PM, Ryan Hendrickson <
> [hidden email]> 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 <[hidden email]> 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 <http://semver.org/>
>
> 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
> [hidden email]
> *[hidden email] <[hidden email]>*
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Jul 9, 2018, at 12:11 PM, Ryan Hendrickson <
> [hidden email]> 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 <[hidden email]>
> 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) <
> [hidden email]> wrote:
>
> Thanks Andy..  +1 for 1.7.1 release.
>
> Thanks & Regards,
> Prashanth
>
> From: Andy LoPresto [mailto:[hidden email] <[hidden email]>]
> Sent: Friday, July 06, 2018 1:34 AM
> To: [hidden email]
> 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
> [hidden email]<mailto:[hidden email] <[hidden email]>>
> [hidden email]<mailto:[hidden email]
> <[hidden email]>>
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Jul 5, 2018, at 11:01 AM, Robert R. Bruno <[hidden email]<mailto:
> [hidden email]>> 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 <[hidden email]<mailto:
> [hidden email]>> 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 <[hidden email]<mailto:
> [hidden email]>> 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
>
>
>
>
Reply | Threaded
Open this post in threaded view
|

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

Andy LoPresto-2
The 1.7.1 release is now complete. I took the unusual step of including the Admin Guide documentation update on the site even though it is not technically part of the release because it was missed as an oversight, and the majority of users will use the live documentation hosted on nifi.apache.org, so it should be as correct as possible. 


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

On Jul 10, 2018, at 8:34 AM, Mark Bean <[hidden email]> wrote:

FYI - NIFI-5368 has been completed and merged to master. It should be
included in 1.7.1.

Thanks,
Mark

On Mon, Jul 9, 2018 at 9:46 PM Andy LoPresto <[hidden email]> wrote:

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
[hidden email]
*[hidden email] <[hidden email]>*
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Jul 9, 2018, at 6:38 PM, Matt Burgess <[hidden email]> 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 <[hidden email]> 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
[hidden email]
[hidden email]
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Jul 9, 2018, at 12:21 PM, Ryan Hendrickson <
[hidden email]> 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 <[hidden email]> 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 <http://semver.org/>

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
[hidden email]
*[hidden email] <[hidden email]>*
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Jul 9, 2018, at 12:11 PM, Ryan Hendrickson <
[hidden email]> 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 <[hidden email]>
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) <
[hidden email]> wrote:

Thanks Andy..  +1 for 1.7.1 release.

Thanks & Regards,
Prashanth

From: Andy LoPresto [mailto:[hidden email] <[hidden email]>]
Sent: Friday, July 06, 2018 1:34 AM
To: [hidden email]
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
[hidden email]<mailto:[hidden email] <[hidden email]>>
[hidden email]<mailto:[hidden email]
<[hidden email]>>
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

On Jul 5, 2018, at 11:01 AM, Robert R. Bruno <[hidden email]<mailto:
[hidden email]>> 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 <[hidden email]<mailto:
[hidden email]>> 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 <[hidden email]<mailto:
[hidden email]>> 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






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

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

Joe Witt
sounds good andy but thanks for flagging that

On Mon, Jul 16, 2018, 10:14 PM Andy LoPresto <[hidden email]> wrote:

> The 1.7.1 release is now complete. I took the unusual step of including
> the Admin Guide documentation update on the site even though it is not
> technically part of the release because it was missed as an oversight, and
> the majority of users will use the live documentation hosted on
> nifi.apache.org, so it should be as correct as possible.
>
>
> Andy LoPresto
> [hidden email]
> *[hidden email] <[hidden email]>*
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Jul 10, 2018, at 8:34 AM, Mark Bean <[hidden email]> wrote:
>
> FYI - NIFI-5368 has been completed and merged to master. It should be
> included in 1.7.1.
>
> Thanks,
> Mark
>
> On Mon, Jul 9, 2018 at 9:46 PM Andy LoPresto <[hidden email]> wrote:
>
> 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
> [hidden email]
> *[hidden email] <[hidden email]>*
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Jul 9, 2018, at 6:38 PM, Matt Burgess <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> [hidden email]
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Jul 9, 2018, at 12:21 PM, Ryan Hendrickson <
> [hidden email]> 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 <[hidden email]> 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 <http://semver.org/>
>
> 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
> [hidden email]
> *[hidden email] <[hidden email]>*
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Jul 9, 2018, at 12:11 PM, Ryan Hendrickson <
> [hidden email]> 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 <[hidden email]>
> 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) <
> [hidden email]> wrote:
>
> Thanks Andy..  +1 for 1.7.1 release.
>
> Thanks & Regards,
> Prashanth
>
> From: Andy LoPresto [mailto:[hidden email] <[hidden email]>]
> Sent: Friday, July 06, 2018 1:34 AM
> To: [hidden email]
> 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
> [hidden email]<mailto:[hidden email] <[hidden email]>>
> [hidden email]<mailto:[hidden email]
> <[hidden email]>>
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Jul 5, 2018, at 11:01 AM, Robert R. Bruno <[hidden email]<mailto:
> [hidden email]>> 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 <[hidden email]<mailto:
> [hidden email]>> 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 <[hidden email]<mailto:
> [hidden email]>> 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
>
>
>
>
>
>