Quantcast

Closing in on a NiFi 0.8.0 release?

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Closing in on a NiFi 0.8.0 release?

Brandon DeVries
Team,

The only unresolved tickets against the 0.8.0 release[1] are for the
removal of code...  With that in mind, does anyone object to trying to push
for this (possibly final) 0.x release?

Brandon

[1]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Closing in on a NiFi 0.8.0 release?

Joe Witt
Brandon,

My concern is the language used when we published this "We support the
newest major release line (0.x, 1.x) and any previous major release
lines for up to one year since the last minor release (0.6.x, 1.5.y)
in that line" within this document [1].

If I read that now it seems like we're saying "if we make a minor
release we're going to support that for up to a year" and so each time
we create a new minor line on a given major line it means we are
resetting the clock.

I do not believe we should give old major lines, such as 0.x, the
ability to drag on the community indefinitely as that reads.  I
believe it should be that we support a given major release line for up
to one year one after a new major release line is provided.

So would like to hear peoples thoughts on that.

If an 0.8 release is to occur the items called out are things which
impact licensing only (specifically the no longer allowed cat-x json
library). I would be far more comfortable with 0.7.3 release which
would be fixing whatever bugs have been addressed.  That avoids the
concern I noted above for this case though i'd still like us to
clarify that language/intent anyway.

Thanks
Joe

On Fri, Feb 24, 2017 at 3:21 PM, Brandon DeVries <[hidden email]> wrote:

> Team,
>
> The only unresolved tickets against the 0.8.0 release[1] are for the
> removal of code...  With that in mind, does anyone object to trying to push
> for this (possibly final) 0.x release?
>
> Brandon
>
> [1]
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Closing in on a NiFi 0.8.0 release?

trkurc
Administrator
I think it is probably worth clarifying the intent of the support language.
I believe the intent was to support 0.x for a year after 1.x was released.
That was how I initially read the document you mentioned. But after a
re-read, I'd echo your concerns about dragging old major lines along.

Tony

On Fri, Feb 24, 2017 at 4:12 PM, Joe Witt <[hidden email]> wrote:

> Brandon,
>
> My concern is the language used when we published this "We support the
> newest major release line (0.x, 1.x) and any previous major release
> lines for up to one year since the last minor release (0.6.x, 1.5.y)
> in that line" within this document [1].
>
> If I read that now it seems like we're saying "if we make a minor
> release we're going to support that for up to a year" and so each time
> we create a new minor line on a given major line it means we are
> resetting the clock.
>
> I do not believe we should give old major lines, such as 0.x, the
> ability to drag on the community indefinitely as that reads.  I
> believe it should be that we support a given major release line for up
> to one year one after a new major release line is provided.
>
> So would like to hear peoples thoughts on that.
>
> If an 0.8 release is to occur the items called out are things which
> impact licensing only (specifically the no longer allowed cat-x json
> library). I would be far more comfortable with 0.7.3 release which
> would be fixing whatever bugs have been addressed.  That avoids the
> concern I noted above for this case though i'd still like us to
> clarify that language/intent anyway.
>
> Thanks
> Joe
>
> On Fri, Feb 24, 2017 at 3:21 PM, Brandon DeVries <[hidden email]> wrote:
> > Team,
> >
> > The only unresolved tickets against the 0.8.0 release[1] are for the
> > removal of code...  With that in mind, does anyone object to trying to
> push
> > for this (possibly final) 0.x release?
> >
> > Brandon
> >
> > [1]
> > <a href="https://issues.apache.org/jira/issues/?jql=project%20%">https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20AND%20resolution%20%3D%
> 20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%
> 20DESC%2C%20created%20ASC
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Closing in on a NiFi 0.8.0 release?

Andy LoPresto-2
Especially as nothing that would be going into the 0.x release is a major feature or changes compatibility (from my understanding), I would +1 the 0.7.3 suggestion. 

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

On Feb 24, 2017, at 2:07 PM, Tony Kurc <[hidden email]> wrote:

I think it is probably worth clarifying the intent of the support language.
I believe the intent was to support 0.x for a year after 1.x was released.
That was how I initially read the document you mentioned. But after a
re-read, I'd echo your concerns about dragging old major lines along.

Tony

On Fri, Feb 24, 2017 at 4:12 PM, Joe Witt <[hidden email]> wrote:

Brandon,

My concern is the language used when we published this "We support the
newest major release line (0.x, 1.x) and any previous major release
lines for up to one year since the last minor release (0.6.x, 1.5.y)
in that line" within this document [1].

If I read that now it seems like we're saying "if we make a minor
release we're going to support that for up to a year" and so each time
we create a new minor line on a given major line it means we are
resetting the clock.

I do not believe we should give old major lines, such as 0.x, the
ability to drag on the community indefinitely as that reads.  I
believe it should be that we support a given major release line for up
to one year one after a new major release line is provided.

So would like to hear peoples thoughts on that.

If an 0.8 release is to occur the items called out are things which
impact licensing only (specifically the no longer allowed cat-x json
library). I would be far more comfortable with 0.7.3 release which
would be fixing whatever bugs have been addressed.  That avoids the
concern I noted above for this case though i'd still like us to
clarify that language/intent anyway.

Thanks
Joe

On Fri, Feb 24, 2017 at 3:21 PM, Brandon DeVries <[hidden email]> wrote:
Team,

The only unresolved tickets against the 0.8.0 release[1] are for the
removal of code...  With that in mind, does anyone object to trying to
push
for this (possibly final) 0.x release?

Brandon

[1]
<a href="https://issues.apache.org/jira/issues/?jql=project%20%" class="">https://issues.apache.org/jira/issues/?jql=project%20%
3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20AND%20resolution%20%3D%
20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%
20DESC%2C%20created%20ASC



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

Re: Closing in on a NiFi 0.8.0 release?

Joe Witt
The 0.8 fixes for licensing remove a processor (gettwitter) at this point.
That I feel requires at least minor.  But avoiding that for now and doing
the bug fix things and doing 073 seems legit.

Will wait and see if anyone else has a different interpretation on the
intent of our one year version guidance and then update the wiki if appears
we have consensus.

Thanks
Joe

On Feb 24, 2017 7:19 PM, "Andy LoPresto" <[hidden email]> wrote:

> Especially as nothing that would be going into the 0.x release is a major
> feature or changes compatibility (from my understanding), I would +1 the
> 0.7.3 suggestion.
>
> Andy LoPresto
> [hidden email]
> *[hidden email] <[hidden email]>*
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Feb 24, 2017, at 2:07 PM, Tony Kurc <[hidden email]> wrote:
>
> I think it is probably worth clarifying the intent of the support language.
> I believe the intent was to support 0.x for a year after 1.x was released.
> That was how I initially read the document you mentioned. But after a
> re-read, I'd echo your concerns about dragging old major lines along.
>
> Tony
>
> On Fri, Feb 24, 2017 at 4:12 PM, Joe Witt <[hidden email]> wrote:
>
> Brandon,
>
> My concern is the language used when we published this "We support the
> newest major release line (0.x, 1.x) and any previous major release
> lines for up to one year since the last minor release (0.6.x, 1.5.y)
> in that line" within this document [1].
>
> If I read that now it seems like we're saying "if we make a minor
> release we're going to support that for up to a year" and so each time
> we create a new minor line on a given major line it means we are
> resetting the clock.
>
> I do not believe we should give old major lines, such as 0.x, the
> ability to drag on the community indefinitely as that reads.  I
> believe it should be that we support a given major release line for up
> to one year one after a new major release line is provided.
>
> So would like to hear peoples thoughts on that.
>
> If an 0.8 release is to occur the items called out are things which
> impact licensing only (specifically the no longer allowed cat-x json
> library). I would be far more comfortable with 0.7.3 release which
> would be fixing whatever bugs have been addressed.  That avoids the
> concern I noted above for this case though i'd still like us to
> clarify that language/intent anyway.
>
> Thanks
> Joe
>
> On Fri, Feb 24, 2017 at 3:21 PM, Brandon DeVries <[hidden email]> wrote:
>
> Team,
>
> The only unresolved tickets against the 0.8.0 release[1] are for the
> removal of code...  With that in mind, does anyone object to trying to
>
> push
>
> for this (possibly final) 0.x release?
>
> Brandon
>
> [1]
> <a href="https://issues.apache.org/jira/issues/?jql=project%20%">https://issues.apache.org/jira/issues/?jql=project%20%
>
> 3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20AND%20resolution%20%3D%
> 20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%
> 20DESC%2C%20created%20ASC
>
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Closing in on a NiFi 0.8.0 release?

Brandon DeVries
Based on Jira, there are 20 tickets marked as fixed in 0.8.0 and nowhere
else in the 0.x line[1].  Highlights from these include:

   - NIFI-2890 - Provenance Repository corruption
   - NIFI-2920 - Swapped FlowFiles are not removed from content repo when a
   queue is emptied.
   - NIFI-3055 - StandardRecordWriter can throw UTFDataFormatException
   - NIFI-3424 - CLONE for 0.x - Unable to generate Provenance Event
   because FlowFile UUID is not set
   - NIFI-3230 - Get/Put JMS broken for simple ActiveMQ SSL URIs
   - NIFI-3403 - NPE in InvokeHTTP
   - NIFI-3362 - Update FlowConfiguration.xsd TimePeriod to match
   FormatUtils
   - NIFI-2861 - ControlRate should accept more than one flow file per
   execution
   - NIFI-3350 - Reduce NiFi startup time by streamlining documentation
   extraction

Are we willing to port all of the tickets from [1] to the 0.7 branch?  Or
rather, which of them would not make the cut?  There are a couple of things
on the list that seem like new features as opposed to pure bug fixes...
although I suppose the difference between a "bug fix" and an "improvement"
is somewhat in the eye of the beholder.

Ultimately, as long as there's a release covering these issues (everything
except the NIFI-2991[2] stuff) I don't particularly care what it's called.
If there are issues left out and I need to run a SNAPSHOT of some sort to
get them, then a further 0.x release doesn't help me anyway, and I'll
withdraw my suggestion.

Brandon

[1]
https://issues.apache.org/jira/issues/?jql=project%20%3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20and%20fixVersion%20not%20in%20(0.2.1%2C%200.3.0%2C%200.4.0%2C0.4.1%2C0.5.0%2C0.5.1%2C0.6.0%2C%200.6.1%2C0.7.0%2C%200.7.1%2C%200.7.2%2C%200.7.3)%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC

[2] https://issues.apache.org/jira/browse/NIFI-2991


On Fri, Feb 24, 2017 at 7:49 PM Joe Witt <[hidden email]> wrote:

> The 0.8 fixes for licensing remove a processor (gettwitter) at this point.
> That I feel requires at least minor.  But avoiding that for now and doing
> the bug fix things and doing 073 seems legit.
>
> Will wait and see if anyone else has a different interpretation on the
> intent of our one year version guidance and then update the wiki if appears
> we have consensus.
>
> Thanks
> Joe
>
> On Feb 24, 2017 7:19 PM, "Andy LoPresto" <[hidden email]> wrote:
>
> > Especially as nothing that would be going into the 0.x release is a major
> > feature or changes compatibility (from my understanding), I would +1 the
> > 0.7.3 suggestion.
> >
> > Andy LoPresto
> > [hidden email]
> > *[hidden email] <[hidden email]>*
> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> >
> > On Feb 24, 2017, at 2:07 PM, Tony Kurc <[hidden email]> wrote:
> >
> > I think it is probably worth clarifying the intent of the support
> language.
> > I believe the intent was to support 0.x for a year after 1.x was
> released.
> > That was how I initially read the document you mentioned. But after a
> > re-read, I'd echo your concerns about dragging old major lines along.
> >
> > Tony
> >
> > On Fri, Feb 24, 2017 at 4:12 PM, Joe Witt <[hidden email]> wrote:
> >
> > Brandon,
> >
> > My concern is the language used when we published this "We support the
> > newest major release line (0.x, 1.x) and any previous major release
> > lines for up to one year since the last minor release (0.6.x, 1.5.y)
> > in that line" within this document [1].
> >
> > If I read that now it seems like we're saying "if we make a minor
> > release we're going to support that for up to a year" and so each time
> > we create a new minor line on a given major line it means we are
> > resetting the clock.
> >
> > I do not believe we should give old major lines, such as 0.x, the
> > ability to drag on the community indefinitely as that reads.  I
> > believe it should be that we support a given major release line for up
> > to one year one after a new major release line is provided.
> >
> > So would like to hear peoples thoughts on that.
> >
> > If an 0.8 release is to occur the items called out are things which
> > impact licensing only (specifically the no longer allowed cat-x json
> > library). I would be far more comfortable with 0.7.3 release which
> > would be fixing whatever bugs have been addressed.  That avoids the
> > concern I noted above for this case though i'd still like us to
> > clarify that language/intent anyway.
> >
> > Thanks
> > Joe
> >
> > On Fri, Feb 24, 2017 at 3:21 PM, Brandon DeVries <[hidden email]> wrote:
> >
> > Team,
> >
> > The only unresolved tickets against the 0.8.0 release[1] are for the
> > removal of code...  With that in mind, does anyone object to trying to
> >
> > push
> >
> > for this (possibly final) 0.x release?
> >
> > Brandon
> >
> > [1]
> > <a href="https://issues.apache.org/jira/issues/?jql=project%20%">https://issues.apache.org/jira/issues/?jql=project%20%
> >
> > 3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20AND%20resolution%20%3D%
> > 20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%
> > 20DESC%2C%20created%20ASC
> >
> >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Closing in on a NiFi 0.8.0 release?

Joe Skora
I think there's a couple considerations related to continuing the 0.x line.

First, as JoeW mentioned the Release Line Management page [1] says we
support a major release for one year, so we should plan to support 0.7.x
for one year from its July 13, 2016 release date [2].

Also, since we considered the 1.0.0 release a beta [3], the 0.x line was
due any fixes, features, and enhancements through the release of 1.1.0 on
November 30th.  So the features and fixes through November 30th should be
backported where possible and appropriate and after that any fixes relating
to security or data loss should be backported for the life of the 0.x line.

Next, I agree with JoeW that we don't want old lines to be a burden on the
community, but I suggest we consider the user base and how practical it is
to expect them to upgrade.  From 0.x to 1.x is a major transition, so I
think we should give more time for that transition than we will might for
1.1 to 1.2.

Finally, 0.x only recently became stable for my users in the last couple of
months, based on the 0.7.1 release with patches added for stability and
corruption issues that is similar to Brandon's list of outstanding 0.x
tickets.  Since the non-beta 1.1.0 release is less than 3 months old and
the transition from 0.x to 1.x is so significant, regardless of our release
policy I would propose we carry on the 0.x line on until 1.x has settled
and been shown to be similarly stable.

Regards,
Joe

[1]
https://cwiki.apache.org/confluence/display/NIFI/Git+Branching+and+Release+Line+Management
[2]
https://lists.apache.org/thread.html/46678ade742887c624c14faf16d187e039827121e35d08f468c3cbfe@%3Cdev.nifi.apache.org%3E
[3]
https://lists.apache.org/thread.html/91a4c272ddf2e80ec2fefd95c2a1df6c37689f4290aba5bdb81afd35@%3Cusers.nifi.apache.org%3E


On Fri, Feb 24, 2017 at 9:58 PM, Brandon DeVries <[hidden email]> wrote:

> Based on Jira, there are 20 tickets marked as fixed in 0.8.0 and nowhere
> else in the 0.x line[1].  Highlights from these include:
>
>    - NIFI-2890 - Provenance Repository corruption
>    - NIFI-2920 - Swapped FlowFiles are not removed from content repo when a
>    queue is emptied.
>    - NIFI-3055 - StandardRecordWriter can throw UTFDataFormatException
>    - NIFI-3424 - CLONE for 0.x - Unable to generate Provenance Event
>    because FlowFile UUID is not set
>    - NIFI-3230 - Get/Put JMS broken for simple ActiveMQ SSL URIs
>    - NIFI-3403 - NPE in InvokeHTTP
>    - NIFI-3362 - Update FlowConfiguration.xsd TimePeriod to match
>    FormatUtils
>    - NIFI-2861 - ControlRate should accept more than one flow file per
>    execution
>    - NIFI-3350 - Reduce NiFi startup time by streamlining documentation
>    extraction
>
> Are we willing to port all of the tickets from [1] to the 0.7 branch?  Or
> rather, which of them would not make the cut?  There are a couple of things
> on the list that seem like new features as opposed to pure bug fixes...
> although I suppose the difference between a "bug fix" and an "improvement"
> is somewhat in the eye of the beholder.
>
> Ultimately, as long as there's a release covering these issues (everything
> except the NIFI-2991[2] stuff) I don't particularly care what it's called.
> If there are issues left out and I need to run a SNAPSHOT of some sort to
> get them, then a further 0.x release doesn't help me anyway, and I'll
> withdraw my suggestion.
>
> Brandon
>
> [1]
> <a href="https://issues.apache.org/jira/issues/?jql=project%20%">https://issues.apache.org/jira/issues/?jql=project%20%
> 3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20and%
> 20fixVersion%20not%20in%20(0.2.1%2C%200.3.0%2C%200.4.0%2C0.
> 4.1%2C0.5.0%2C0.5.1%2C0.6.0%2C%200.6.1%2C0.7.0%2C%200.7.1%
> 2C%200.7.2%2C%200.7.3)%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%
> 20created%20ASC
>
> [2] https://issues.apache.org/jira/browse/NIFI-2991
>
>
> On Fri, Feb 24, 2017 at 7:49 PM Joe Witt <[hidden email]> wrote:
>
> > The 0.8 fixes for licensing remove a processor (gettwitter) at this
> point.
> > That I feel requires at least minor.  But avoiding that for now and doing
> > the bug fix things and doing 073 seems legit.
> >
> > Will wait and see if anyone else has a different interpretation on the
> > intent of our one year version guidance and then update the wiki if
> appears
> > we have consensus.
> >
> > Thanks
> > Joe
> >
> > On Feb 24, 2017 7:19 PM, "Andy LoPresto" <[hidden email]> wrote:
> >
> > > Especially as nothing that would be going into the 0.x release is a
> major
> > > feature or changes compatibility (from my understanding), I would +1
> the
> > > 0.7.3 suggestion.
> > >
> > > Andy LoPresto
> > > [hidden email]
> > > *[hidden email] <[hidden email]>*
> > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> > >
> > > On Feb 24, 2017, at 2:07 PM, Tony Kurc <[hidden email]> wrote:
> > >
> > > I think it is probably worth clarifying the intent of the support
> > language.
> > > I believe the intent was to support 0.x for a year after 1.x was
> > released.
> > > That was how I initially read the document you mentioned. But after a
> > > re-read, I'd echo your concerns about dragging old major lines along.
> > >
> > > Tony
> > >
> > > On Fri, Feb 24, 2017 at 4:12 PM, Joe Witt <[hidden email]> wrote:
> > >
> > > Brandon,
> > >
> > > My concern is the language used when we published this "We support the
> > > newest major release line (0.x, 1.x) and any previous major release
> > > lines for up to one year since the last minor release (0.6.x, 1.5.y)
> > > in that line" within this document [1].
> > >
> > > If I read that now it seems like we're saying "if we make a minor
> > > release we're going to support that for up to a year" and so each time
> > > we create a new minor line on a given major line it means we are
> > > resetting the clock.
> > >
> > > I do not believe we should give old major lines, such as 0.x, the
> > > ability to drag on the community indefinitely as that reads.  I
> > > believe it should be that we support a given major release line for up
> > > to one year one after a new major release line is provided.
> > >
> > > So would like to hear peoples thoughts on that.
> > >
> > > If an 0.8 release is to occur the items called out are things which
> > > impact licensing only (specifically the no longer allowed cat-x json
> > > library). I would be far more comfortable with 0.7.3 release which
> > > would be fixing whatever bugs have been addressed.  That avoids the
> > > concern I noted above for this case though i'd still like us to
> > > clarify that language/intent anyway.
> > >
> > > Thanks
> > > Joe
> > >
> > > On Fri, Feb 24, 2017 at 3:21 PM, Brandon DeVries <[hidden email]> wrote:
> > >
> > > Team,
> > >
> > > The only unresolved tickets against the 0.8.0 release[1] are for the
> > > removal of code...  With that in mind, does anyone object to trying to
> > >
> > > push
> > >
> > > for this (possibly final) 0.x release?
> > >
> > > Brandon
> > >
> > > [1]
> > > <a href="https://issues.apache.org/jira/issues/?jql=project%20%">https://issues.apache.org/jira/issues/?jql=project%20%
> > >
> > > 3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20AND%20resolution%20%3D%
> > > 20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%
> > > 20DESC%2C%20created%20ASC
> > >
> > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Closing in on a NiFi 0.8.0 release?

Bryan Bende
Joe,

Just wanted to clarify that I don't believe the 1.0.0 release was a BETA.

There was a 1.0.0-BETA release on 8/5 to gather feedback and testing
from the community, and the regular 1.0.0 release on 8/26.

http://central.maven.org/maven2/org/apache/nifi/nifi-assembly/1.0.0-BETA/  (8/5)
http://central.maven.org/maven2/org/apache/nifi/nifi-assembly/1.0.0/ (8/26)

-Bryan


On Mon, Feb 27, 2017 at 9:42 AM, Joe Skora <[hidden email]> wrote:

> I think there's a couple considerations related to continuing the 0.x line.
>
> First, as JoeW mentioned the Release Line Management page [1] says we
> support a major release for one year, so we should plan to support 0.7.x
> for one year from its July 13, 2016 release date [2].
>
> Also, since we considered the 1.0.0 release a beta [3], the 0.x line was
> due any fixes, features, and enhancements through the release of 1.1.0 on
> November 30th.  So the features and fixes through November 30th should be
> backported where possible and appropriate and after that any fixes relating
> to security or data loss should be backported for the life of the 0.x line.
>
> Next, I agree with JoeW that we don't want old lines to be a burden on the
> community, but I suggest we consider the user base and how practical it is
> to expect them to upgrade.  From 0.x to 1.x is a major transition, so I
> think we should give more time for that transition than we will might for
> 1.1 to 1.2.
>
> Finally, 0.x only recently became stable for my users in the last couple of
> months, based on the 0.7.1 release with patches added for stability and
> corruption issues that is similar to Brandon's list of outstanding 0.x
> tickets.  Since the non-beta 1.1.0 release is less than 3 months old and
> the transition from 0.x to 1.x is so significant, regardless of our release
> policy I would propose we carry on the 0.x line on until 1.x has settled
> and been shown to be similarly stable.
>
> Regards,
> Joe
>
> [1]
> https://cwiki.apache.org/confluence/display/NIFI/Git+Branching+and+Release+Line+Management
> [2]
> https://lists.apache.org/thread.html/46678ade742887c624c14faf16d187e039827121e35d08f468c3cbfe@%3Cdev.nifi.apache.org%3E
> [3]
> https://lists.apache.org/thread.html/91a4c272ddf2e80ec2fefd95c2a1df6c37689f4290aba5bdb81afd35@%3Cusers.nifi.apache.org%3E
>
>
> On Fri, Feb 24, 2017 at 9:58 PM, Brandon DeVries <[hidden email]> wrote:
>
>> Based on Jira, there are 20 tickets marked as fixed in 0.8.0 and nowhere
>> else in the 0.x line[1].  Highlights from these include:
>>
>>    - NIFI-2890 - Provenance Repository corruption
>>    - NIFI-2920 - Swapped FlowFiles are not removed from content repo when a
>>    queue is emptied.
>>    - NIFI-3055 - StandardRecordWriter can throw UTFDataFormatException
>>    - NIFI-3424 - CLONE for 0.x - Unable to generate Provenance Event
>>    because FlowFile UUID is not set
>>    - NIFI-3230 - Get/Put JMS broken for simple ActiveMQ SSL URIs
>>    - NIFI-3403 - NPE in InvokeHTTP
>>    - NIFI-3362 - Update FlowConfiguration.xsd TimePeriod to match
>>    FormatUtils
>>    - NIFI-2861 - ControlRate should accept more than one flow file per
>>    execution
>>    - NIFI-3350 - Reduce NiFi startup time by streamlining documentation
>>    extraction
>>
>> Are we willing to port all of the tickets from [1] to the 0.7 branch?  Or
>> rather, which of them would not make the cut?  There are a couple of things
>> on the list that seem like new features as opposed to pure bug fixes...
>> although I suppose the difference between a "bug fix" and an "improvement"
>> is somewhat in the eye of the beholder.
>>
>> Ultimately, as long as there's a release covering these issues (everything
>> except the NIFI-2991[2] stuff) I don't particularly care what it's called.
>> If there are issues left out and I need to run a SNAPSHOT of some sort to
>> get them, then a further 0.x release doesn't help me anyway, and I'll
>> withdraw my suggestion.
>>
>> Brandon
>>
>> [1]
>> <a href="https://issues.apache.org/jira/issues/?jql=project%20%">https://issues.apache.org/jira/issues/?jql=project%20%
>> 3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20and%
>> 20fixVersion%20not%20in%20(0.2.1%2C%200.3.0%2C%200.4.0%2C0.
>> 4.1%2C0.5.0%2C0.5.1%2C0.6.0%2C%200.6.1%2C0.7.0%2C%200.7.1%
>> 2C%200.7.2%2C%200.7.3)%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%
>> 20created%20ASC
>>
>> [2] https://issues.apache.org/jira/browse/NIFI-2991
>>
>>
>> On Fri, Feb 24, 2017 at 7:49 PM Joe Witt <[hidden email]> wrote:
>>
>> > The 0.8 fixes for licensing remove a processor (gettwitter) at this
>> point.
>> > That I feel requires at least minor.  But avoiding that for now and doing
>> > the bug fix things and doing 073 seems legit.
>> >
>> > Will wait and see if anyone else has a different interpretation on the
>> > intent of our one year version guidance and then update the wiki if
>> appears
>> > we have consensus.
>> >
>> > Thanks
>> > Joe
>> >
>> > On Feb 24, 2017 7:19 PM, "Andy LoPresto" <[hidden email]> wrote:
>> >
>> > > Especially as nothing that would be going into the 0.x release is a
>> major
>> > > feature or changes compatibility (from my understanding), I would +1
>> the
>> > > 0.7.3 suggestion.
>> > >
>> > > Andy LoPresto
>> > > [hidden email]
>> > > *[hidden email] <[hidden email]>*
>> > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>> > >
>> > > On Feb 24, 2017, at 2:07 PM, Tony Kurc <[hidden email]> wrote:
>> > >
>> > > I think it is probably worth clarifying the intent of the support
>> > language.
>> > > I believe the intent was to support 0.x for a year after 1.x was
>> > released.
>> > > That was how I initially read the document you mentioned. But after a
>> > > re-read, I'd echo your concerns about dragging old major lines along.
>> > >
>> > > Tony
>> > >
>> > > On Fri, Feb 24, 2017 at 4:12 PM, Joe Witt <[hidden email]> wrote:
>> > >
>> > > Brandon,
>> > >
>> > > My concern is the language used when we published this "We support the
>> > > newest major release line (0.x, 1.x) and any previous major release
>> > > lines for up to one year since the last minor release (0.6.x, 1.5.y)
>> > > in that line" within this document [1].
>> > >
>> > > If I read that now it seems like we're saying "if we make a minor
>> > > release we're going to support that for up to a year" and so each time
>> > > we create a new minor line on a given major line it means we are
>> > > resetting the clock.
>> > >
>> > > I do not believe we should give old major lines, such as 0.x, the
>> > > ability to drag on the community indefinitely as that reads.  I
>> > > believe it should be that we support a given major release line for up
>> > > to one year one after a new major release line is provided.
>> > >
>> > > So would like to hear peoples thoughts on that.
>> > >
>> > > If an 0.8 release is to occur the items called out are things which
>> > > impact licensing only (specifically the no longer allowed cat-x json
>> > > library). I would be far more comfortable with 0.7.3 release which
>> > > would be fixing whatever bugs have been addressed.  That avoids the
>> > > concern I noted above for this case though i'd still like us to
>> > > clarify that language/intent anyway.
>> > >
>> > > Thanks
>> > > Joe
>> > >
>> > > On Fri, Feb 24, 2017 at 3:21 PM, Brandon DeVries <[hidden email]> wrote:
>> > >
>> > > Team,
>> > >
>> > > The only unresolved tickets against the 0.8.0 release[1] are for the
>> > > removal of code...  With that in mind, does anyone object to trying to
>> > >
>> > > push
>> > >
>> > > for this (possibly final) 0.x release?
>> > >
>> > > Brandon
>> > >
>> > > [1]
>> > > <a href="https://issues.apache.org/jira/issues/?jql=project%20%">https://issues.apache.org/jira/issues/?jql=project%20%
>> > >
>> > > 3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20AND%20resolution%20%3D%
>> > > 20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%
>> > > 20DESC%2C%20created%20ASC
>> > >
>> > >
>> > >
>> >
>>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Closing in on a NiFi 0.8.0 release?

Joe Witt
In reply to this post by Joe Skora
Joe

1.0.0 was not a beta release.

1.0.0-beta was a beta release.

The intent of the language was we support the old major line for one year
once there is a major release.  It is of course imperative to respect that
folks cannot migrate as quickly as we would always like.  But this sort of
concern is precisely why we have such a document.

I propose we clarify the language to clearly and simply state that once a
new major release line release has occurred we will support the old release
line for up to one year.   This does not distinguish between minor or
incremental.  There is already language for that.

The stability comment is an unclear line to debate.  The act of voting on a
release is the point at which the community agrees and asserts the fitness
of a release.  We have no other open and clear mechanism for doing so.

I think the question of whether an 0.8 can happen is no longer tied to the
recent portions of this thread.  It would need am RM and vote.

As I mentioned the other day I'll go ahead and update the versioning
guidance barring any objection or alternative proposal.  I'll wait another
day or so in case you would like to propose alternative language for the
commitment we make as a community to our users and ourselves.

Thanks
Joe

On Feb 27, 2017 9:42 AM, "Joe Skora" <[hidden email]> wrote:

> I think there's a couple considerations related to continuing the 0.x line.
>
> First, as JoeW mentioned the Release Line Management page [1] says we
> support a major release for one year, so we should plan to support 0.7.x
> for one year from its July 13, 2016 release date [2].
>
> Also, since we considered the 1.0.0 release a beta [3], the 0.x line was
> due any fixes, features, and enhancements through the release of 1.1.0 on
> November 30th.  So the features and fixes through November 30th should be
> backported where possible and appropriate and after that any fixes relating
> to security or data loss should be backported for the life of the 0.x line.
>
> Next, I agree with JoeW that we don't want old lines to be a burden on the
> community, but I suggest we consider the user base and how practical it is
> to expect them to upgrade.  From 0.x to 1.x is a major transition, so I
> think we should give more time for that transition than we will might for
> 1.1 to 1.2.
>
> Finally, 0.x only recently became stable for my users in the last couple of
> months, based on the 0.7.1 release with patches added for stability and
> corruption issues that is similar to Brandon's list of outstanding 0.x
> tickets.  Since the non-beta 1.1.0 release is less than 3 months old and
> the transition from 0.x to 1.x is so significant, regardless of our release
> policy I would propose we carry on the 0.x line on until 1.x has settled
> and been shown to be similarly stable.
>
> Regards,
> Joe
>
> [1]
> https://cwiki.apache.org/confluence/display/NIFI/Git+
> Branching+and+Release+Line+Management
> [2]
> https://lists.apache.org/thread.html/46678ade742887c624c14faf16d187
> e039827121e35d08f468c3cbfe@%3Cdev.nifi.apache.org%3E
> [3]
> https://lists.apache.org/thread.html/91a4c272ddf2e80ec2fefd95c2a1df
> 6c37689f4290aba5bdb81afd35@%3Cusers.nifi.apache.org%3E
>
>
> On Fri, Feb 24, 2017 at 9:58 PM, Brandon DeVries <[hidden email]> wrote:
>
> > Based on Jira, there are 20 tickets marked as fixed in 0.8.0 and nowhere
> > else in the 0.x line[1].  Highlights from these include:
> >
> >    - NIFI-2890 - Provenance Repository corruption
> >    - NIFI-2920 - Swapped FlowFiles are not removed from content repo
> when a
> >    queue is emptied.
> >    - NIFI-3055 - StandardRecordWriter can throw UTFDataFormatException
> >    - NIFI-3424 - CLONE for 0.x - Unable to generate Provenance Event
> >    because FlowFile UUID is not set
> >    - NIFI-3230 - Get/Put JMS broken for simple ActiveMQ SSL URIs
> >    - NIFI-3403 - NPE in InvokeHTTP
> >    - NIFI-3362 - Update FlowConfiguration.xsd TimePeriod to match
> >    FormatUtils
> >    - NIFI-2861 - ControlRate should accept more than one flow file per
> >    execution
> >    - NIFI-3350 - Reduce NiFi startup time by streamlining documentation
> >    extraction
> >
> > Are we willing to port all of the tickets from [1] to the 0.7 branch?  Or
> > rather, which of them would not make the cut?  There are a couple of
> things
> > on the list that seem like new features as opposed to pure bug fixes...
> > although I suppose the difference between a "bug fix" and an
> "improvement"
> > is somewhat in the eye of the beholder.
> >
> > Ultimately, as long as there's a release covering these issues
> (everything
> > except the NIFI-2991[2] stuff) I don't particularly care what it's
> called.
> > If there are issues left out and I need to run a SNAPSHOT of some sort to
> > get them, then a further 0.x release doesn't help me anyway, and I'll
> > withdraw my suggestion.
> >
> > Brandon
> >
> > [1]
> > <a href="https://issues.apache.org/jira/issues/?jql=project%20%">https://issues.apache.org/jira/issues/?jql=project%20%
> > 3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20and%
> > 20fixVersion%20not%20in%20(0.2.1%2C%200.3.0%2C%200.4.0%2C0.
> > 4.1%2C0.5.0%2C0.5.1%2C0.6.0%2C%200.6.1%2C0.7.0%2C%200.7.1%
> > 2C%200.7.2%2C%200.7.3)%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%
> > 20created%20ASC
> >
> > [2] https://issues.apache.org/jira/browse/NIFI-2991
> >
> >
> > On Fri, Feb 24, 2017 at 7:49 PM Joe Witt <[hidden email]> wrote:
> >
> > > The 0.8 fixes for licensing remove a processor (gettwitter) at this
> > point.
> > > That I feel requires at least minor.  But avoiding that for now and
> doing
> > > the bug fix things and doing 073 seems legit.
> > >
> > > Will wait and see if anyone else has a different interpretation on the
> > > intent of our one year version guidance and then update the wiki if
> > appears
> > > we have consensus.
> > >
> > > Thanks
> > > Joe
> > >
> > > On Feb 24, 2017 7:19 PM, "Andy LoPresto" <[hidden email]> wrote:
> > >
> > > > Especially as nothing that would be going into the 0.x release is a
> > major
> > > > feature or changes compatibility (from my understanding), I would +1
> > the
> > > > 0.7.3 suggestion.
> > > >
> > > > Andy LoPresto
> > > > [hidden email]
> > > > *[hidden email] <[hidden email]>*
> > > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> > > >
> > > > On Feb 24, 2017, at 2:07 PM, Tony Kurc <[hidden email]> wrote:
> > > >
> > > > I think it is probably worth clarifying the intent of the support
> > > language.
> > > > I believe the intent was to support 0.x for a year after 1.x was
> > > released.
> > > > That was how I initially read the document you mentioned. But after a
> > > > re-read, I'd echo your concerns about dragging old major lines along.
> > > >
> > > > Tony
> > > >
> > > > On Fri, Feb 24, 2017 at 4:12 PM, Joe Witt <[hidden email]>
> wrote:
> > > >
> > > > Brandon,
> > > >
> > > > My concern is the language used when we published this "We support
> the
> > > > newest major release line (0.x, 1.x) and any previous major release
> > > > lines for up to one year since the last minor release (0.6.x, 1.5.y)
> > > > in that line" within this document [1].
> > > >
> > > > If I read that now it seems like we're saying "if we make a minor
> > > > release we're going to support that for up to a year" and so each
> time
> > > > we create a new minor line on a given major line it means we are
> > > > resetting the clock.
> > > >
> > > > I do not believe we should give old major lines, such as 0.x, the
> > > > ability to drag on the community indefinitely as that reads.  I
> > > > believe it should be that we support a given major release line for
> up
> > > > to one year one after a new major release line is provided.
> > > >
> > > > So would like to hear peoples thoughts on that.
> > > >
> > > > If an 0.8 release is to occur the items called out are things which
> > > > impact licensing only (specifically the no longer allowed cat-x json
> > > > library). I would be far more comfortable with 0.7.3 release which
> > > > would be fixing whatever bugs have been addressed.  That avoids the
> > > > concern I noted above for this case though i'd still like us to
> > > > clarify that language/intent anyway.
> > > >
> > > > Thanks
> > > > Joe
> > > >
> > > > On Fri, Feb 24, 2017 at 3:21 PM, Brandon DeVries <[hidden email]>
> wrote:
> > > >
> > > > Team,
> > > >
> > > > The only unresolved tickets against the 0.8.0 release[1] are for the
> > > > removal of code...  With that in mind, does anyone object to trying
> to
> > > >
> > > > push
> > > >
> > > > for this (possibly final) 0.x release?
> > > >
> > > > Brandon
> > > >
> > > > [1]
> > > > <a href="https://issues.apache.org/jira/issues/?jql=project%20%">https://issues.apache.org/jira/issues/?jql=project%20%
> > > >
> > > > 3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20AND%20resolution%20%3D%
> > > > 20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%
> > > > 20DESC%2C%20created%20ASC
> > > >
> > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Closing in on a NiFi 0.8.0 release?

Joe Skora
Sorry for the confusion regarding 1.0.0-BETA vs 1.0.0, my bad.

As for stability, I don't mean build and test stability but real world
stability feedback that has led to various repository fixes including the
1.x line transition to the schema based provenance and newly refactored
provenance repository.

Again, apologies for the beta confusion.

On Mon, Feb 27, 2017 at 10:24 AM, Joe Witt <[hidden email]> wrote:

> Joe
>
> 1.0.0 was not a beta release.
>
> 1.0.0-beta was a beta release.
>
> The intent of the language was we support the old major line for one year
> once there is a major release.  It is of course imperative to respect that
> folks cannot migrate as quickly as we would always like.  But this sort of
> concern is precisely why we have such a document.
>
> I propose we clarify the language to clearly and simply state that once a
> new major release line release has occurred we will support the old release
> line for up to one year.   This does not distinguish between minor or
> incremental.  There is already language for that.
>
> The stability comment is an unclear line to debate.  The act of voting on a
> release is the point at which the community agrees and asserts the fitness
> of a release.  We have no other open and clear mechanism for doing so.
>
> I think the question of whether an 0.8 can happen is no longer tied to the
> recent portions of this thread.  It would need am RM and vote.
>
> As I mentioned the other day I'll go ahead and update the versioning
> guidance barring any objection or alternative proposal.  I'll wait another
> day or so in case you would like to propose alternative language for the
> commitment we make as a community to our users and ourselves.
>
> Thanks
> Joe
>
> On Feb 27, 2017 9:42 AM, "Joe Skora" <[hidden email]> wrote:
>
> > I think there's a couple considerations related to continuing the 0.x
> line.
> >
> > First, as JoeW mentioned the Release Line Management page [1] says we
> > support a major release for one year, so we should plan to support 0.7.x
> > for one year from its July 13, 2016 release date [2].
> >
> > Also, since we considered the 1.0.0 release a beta [3], the 0.x line was
> > due any fixes, features, and enhancements through the release of 1.1.0 on
> > November 30th.  So the features and fixes through November 30th should be
> > backported where possible and appropriate and after that any fixes
> relating
> > to security or data loss should be backported for the life of the 0.x
> line.
> >
> > Next, I agree with JoeW that we don't want old lines to be a burden on
> the
> > community, but I suggest we consider the user base and how practical it
> is
> > to expect them to upgrade.  From 0.x to 1.x is a major transition, so I
> > think we should give more time for that transition than we will might for
> > 1.1 to 1.2.
> >
> > Finally, 0.x only recently became stable for my users in the last couple
> of
> > months, based on the 0.7.1 release with patches added for stability and
> > corruption issues that is similar to Brandon's list of outstanding 0.x
> > tickets.  Since the non-beta 1.1.0 release is less than 3 months old and
> > the transition from 0.x to 1.x is so significant, regardless of our
> release
> > policy I would propose we carry on the 0.x line on until 1.x has settled
> > and been shown to be similarly stable.
> >
> > Regards,
> > Joe
> >
> > [1]
> > https://cwiki.apache.org/confluence/display/NIFI/Git+
> > Branching+and+Release+Line+Management
> > [2]
> > https://lists.apache.org/thread.html/46678ade742887c624c14faf16d187
> > e039827121e35d08f468c3cbfe@%3Cdev.nifi.apache.org%3E
> > [3]
> > https://lists.apache.org/thread.html/91a4c272ddf2e80ec2fefd95c2a1df
> > 6c37689f4290aba5bdb81afd35@%3Cusers.nifi.apache.org%3E
> >
> >
> > On Fri, Feb 24, 2017 at 9:58 PM, Brandon DeVries <[hidden email]> wrote:
> >
> > > Based on Jira, there are 20 tickets marked as fixed in 0.8.0 and
> nowhere
> > > else in the 0.x line[1].  Highlights from these include:
> > >
> > >    - NIFI-2890 - Provenance Repository corruption
> > >    - NIFI-2920 - Swapped FlowFiles are not removed from content repo
> > when a
> > >    queue is emptied.
> > >    - NIFI-3055 - StandardRecordWriter can throw UTFDataFormatException
> > >    - NIFI-3424 - CLONE for 0.x - Unable to generate Provenance Event
> > >    because FlowFile UUID is not set
> > >    - NIFI-3230 - Get/Put JMS broken for simple ActiveMQ SSL URIs
> > >    - NIFI-3403 - NPE in InvokeHTTP
> > >    - NIFI-3362 - Update FlowConfiguration.xsd TimePeriod to match
> > >    FormatUtils
> > >    - NIFI-2861 - ControlRate should accept more than one flow file per
> > >    execution
> > >    - NIFI-3350 - Reduce NiFi startup time by streamlining documentation
> > >    extraction
> > >
> > > Are we willing to port all of the tickets from [1] to the 0.7 branch?
> Or
> > > rather, which of them would not make the cut?  There are a couple of
> > things
> > > on the list that seem like new features as opposed to pure bug fixes...
> > > although I suppose the difference between a "bug fix" and an
> > "improvement"
> > > is somewhat in the eye of the beholder.
> > >
> > > Ultimately, as long as there's a release covering these issues
> > (everything
> > > except the NIFI-2991[2] stuff) I don't particularly care what it's
> > called.
> > > If there are issues left out and I need to run a SNAPSHOT of some sort
> to
> > > get them, then a further 0.x release doesn't help me anyway, and I'll
> > > withdraw my suggestion.
> > >
> > > Brandon
> > >
> > > [1]
> > > <a href="https://issues.apache.org/jira/issues/?jql=project%20%">https://issues.apache.org/jira/issues/?jql=project%20%
> > > 3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20and%
> > > 20fixVersion%20not%20in%20(0.2.1%2C%200.3.0%2C%200.4.0%2C0.
> > > 4.1%2C0.5.0%2C0.5.1%2C0.6.0%2C%200.6.1%2C0.7.0%2C%200.7.1%
> > > 2C%200.7.2%2C%200.7.3)%20ORDER%20BY%20due%20ASC%2C%
> 20priority%20DESC%2C%
> > > 20created%20ASC
> > >
> > > [2] https://issues.apache.org/jira/browse/NIFI-2991
> > >
> > >
> > > On Fri, Feb 24, 2017 at 7:49 PM Joe Witt <[hidden email]> wrote:
> > >
> > > > The 0.8 fixes for licensing remove a processor (gettwitter) at this
> > > point.
> > > > That I feel requires at least minor.  But avoiding that for now and
> > doing
> > > > the bug fix things and doing 073 seems legit.
> > > >
> > > > Will wait and see if anyone else has a different interpretation on
> the
> > > > intent of our one year version guidance and then update the wiki if
> > > appears
> > > > we have consensus.
> > > >
> > > > Thanks
> > > > Joe
> > > >
> > > > On Feb 24, 2017 7:19 PM, "Andy LoPresto" <[hidden email]>
> wrote:
> > > >
> > > > > Especially as nothing that would be going into the 0.x release is a
> > > major
> > > > > feature or changes compatibility (from my understanding), I would
> +1
> > > the
> > > > > 0.7.3 suggestion.
> > > > >
> > > > > Andy LoPresto
> > > > > [hidden email]
> > > > > *[hidden email] <[hidden email]>*
> > > > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> > > > >
> > > > > On Feb 24, 2017, at 2:07 PM, Tony Kurc <[hidden email]> wrote:
> > > > >
> > > > > I think it is probably worth clarifying the intent of the support
> > > > language.
> > > > > I believe the intent was to support 0.x for a year after 1.x was
> > > > released.
> > > > > That was how I initially read the document you mentioned. But
> after a
> > > > > re-read, I'd echo your concerns about dragging old major lines
> along.
> > > > >
> > > > > Tony
> > > > >
> > > > > On Fri, Feb 24, 2017 at 4:12 PM, Joe Witt <[hidden email]>
> > wrote:
> > > > >
> > > > > Brandon,
> > > > >
> > > > > My concern is the language used when we published this "We support
> > the
> > > > > newest major release line (0.x, 1.x) and any previous major release
> > > > > lines for up to one year since the last minor release (0.6.x,
> 1.5.y)
> > > > > in that line" within this document [1].
> > > > >
> > > > > If I read that now it seems like we're saying "if we make a minor
> > > > > release we're going to support that for up to a year" and so each
> > time
> > > > > we create a new minor line on a given major line it means we are
> > > > > resetting the clock.
> > > > >
> > > > > I do not believe we should give old major lines, such as 0.x, the
> > > > > ability to drag on the community indefinitely as that reads.  I
> > > > > believe it should be that we support a given major release line for
> > up
> > > > > to one year one after a new major release line is provided.
> > > > >
> > > > > So would like to hear peoples thoughts on that.
> > > > >
> > > > > If an 0.8 release is to occur the items called out are things which
> > > > > impact licensing only (specifically the no longer allowed cat-x
> json
> > > > > library). I would be far more comfortable with 0.7.3 release which
> > > > > would be fixing whatever bugs have been addressed.  That avoids the
> > > > > concern I noted above for this case though i'd still like us to
> > > > > clarify that language/intent anyway.
> > > > >
> > > > > Thanks
> > > > > Joe
> > > > >
> > > > > On Fri, Feb 24, 2017 at 3:21 PM, Brandon DeVries <[hidden email]>
> > wrote:
> > > > >
> > > > > Team,
> > > > >
> > > > > The only unresolved tickets against the 0.8.0 release[1] are for
> the
> > > > > removal of code...  With that in mind, does anyone object to trying
> > to
> > > > >
> > > > > push
> > > > >
> > > > > for this (possibly final) 0.x release?
> > > > >
> > > > > Brandon
> > > > >
> > > > > [1]
> > > > > <a href="https://issues.apache.org/jira/issues/?jql=project%20%">https://issues.apache.org/jira/issues/?jql=project%20%
> > > > >
> > > > > 3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20AND%
> 20resolution%20%3D%
> > > > > 20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%
> > > > > 20DESC%2C%20created%20ASC
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Closing in on a NiFi 0.8.0 release?

Michael Moser
All,

I have started going through JIRA and identifying remaining issues against
the 0.x branch to prepare for a release, and I've worked a couple of the
JSON.org Cat-x license issues on that branch.

I would like to volunteer to be release manager for a 0.7.3 release, if you
will let me try.  ;-)

-- Mike


On Mon, Feb 27, 2017 at 10:55 AM, Joe Skora <[hidden email]> wrote:

> Sorry for the confusion regarding 1.0.0-BETA vs 1.0.0, my bad.
>
> As for stability, I don't mean build and test stability but real world
> stability feedback that has led to various repository fixes including the
> 1.x line transition to the schema based provenance and newly refactored
> provenance repository.
>
> Again, apologies for the beta confusion.
>
> On Mon, Feb 27, 2017 at 10:24 AM, Joe Witt <[hidden email]> wrote:
>
> > Joe
> >
> > 1.0.0 was not a beta release.
> >
> > 1.0.0-beta was a beta release.
> >
> > The intent of the language was we support the old major line for one year
> > once there is a major release.  It is of course imperative to respect
> that
> > folks cannot migrate as quickly as we would always like.  But this sort
> of
> > concern is precisely why we have such a document.
> >
> > I propose we clarify the language to clearly and simply state that once a
> > new major release line release has occurred we will support the old
> release
> > line for up to one year.   This does not distinguish between minor or
> > incremental.  There is already language for that.
> >
> > The stability comment is an unclear line to debate.  The act of voting
> on a
> > release is the point at which the community agrees and asserts the
> fitness
> > of a release.  We have no other open and clear mechanism for doing so.
> >
> > I think the question of whether an 0.8 can happen is no longer tied to
> the
> > recent portions of this thread.  It would need am RM and vote.
> >
> > As I mentioned the other day I'll go ahead and update the versioning
> > guidance barring any objection or alternative proposal.  I'll wait
> another
> > day or so in case you would like to propose alternative language for the
> > commitment we make as a community to our users and ourselves.
> >
> > Thanks
> > Joe
> >
> > On Feb 27, 2017 9:42 AM, "Joe Skora" <[hidden email]> wrote:
> >
> > > I think there's a couple considerations related to continuing the 0.x
> > line.
> > >
> > > First, as JoeW mentioned the Release Line Management page [1] says we
> > > support a major release for one year, so we should plan to support
> 0.7.x
> > > for one year from its July 13, 2016 release date [2].
> > >
> > > Also, since we considered the 1.0.0 release a beta [3], the 0.x line
> was
> > > due any fixes, features, and enhancements through the release of 1.1.0
> on
> > > November 30th.  So the features and fixes through November 30th should
> be
> > > backported where possible and appropriate and after that any fixes
> > relating
> > > to security or data loss should be backported for the life of the 0.x
> > line.
> > >
> > > Next, I agree with JoeW that we don't want old lines to be a burden on
> > the
> > > community, but I suggest we consider the user base and how practical it
> > is
> > > to expect them to upgrade.  From 0.x to 1.x is a major transition, so I
> > > think we should give more time for that transition than we will might
> for
> > > 1.1 to 1.2.
> > >
> > > Finally, 0.x only recently became stable for my users in the last
> couple
> > of
> > > months, based on the 0.7.1 release with patches added for stability and
> > > corruption issues that is similar to Brandon's list of outstanding 0.x
> > > tickets.  Since the non-beta 1.1.0 release is less than 3 months old
> and
> > > the transition from 0.x to 1.x is so significant, regardless of our
> > release
> > > policy I would propose we carry on the 0.x line on until 1.x has
> settled
> > > and been shown to be similarly stable.
> > >
> > > Regards,
> > > Joe
> > >
> > > [1]
> > > https://cwiki.apache.org/confluence/display/NIFI/Git+
> > > Branching+and+Release+Line+Management
> > > [2]
> > > https://lists.apache.org/thread.html/46678ade742887c624c14faf16d187
> > > e039827121e35d08f468c3cbfe@%3Cdev.nifi.apache.org%3E
> > > [3]
> > > https://lists.apache.org/thread.html/91a4c272ddf2e80ec2fefd95c2a1df
> > > 6c37689f4290aba5bdb81afd35@%3Cusers.nifi.apache.org%3E
> > >
> > >
> > > On Fri, Feb 24, 2017 at 9:58 PM, Brandon DeVries <[hidden email]> wrote:
> > >
> > > > Based on Jira, there are 20 tickets marked as fixed in 0.8.0 and
> > nowhere
> > > > else in the 0.x line[1].  Highlights from these include:
> > > >
> > > >    - NIFI-2890 - Provenance Repository corruption
> > > >    - NIFI-2920 - Swapped FlowFiles are not removed from content repo
> > > when a
> > > >    queue is emptied.
> > > >    - NIFI-3055 - StandardRecordWriter can throw
> UTFDataFormatException
> > > >    - NIFI-3424 - CLONE for 0.x - Unable to generate Provenance Event
> > > >    because FlowFile UUID is not set
> > > >    - NIFI-3230 - Get/Put JMS broken for simple ActiveMQ SSL URIs
> > > >    - NIFI-3403 - NPE in InvokeHTTP
> > > >    - NIFI-3362 - Update FlowConfiguration.xsd TimePeriod to match
> > > >    FormatUtils
> > > >    - NIFI-2861 - ControlRate should accept more than one flow file
> per
> > > >    execution
> > > >    - NIFI-3350 - Reduce NiFi startup time by streamlining
> documentation
> > > >    extraction
> > > >
> > > > Are we willing to port all of the tickets from [1] to the 0.7 branch?
> > Or
> > > > rather, which of them would not make the cut?  There are a couple of
> > > things
> > > > on the list that seem like new features as opposed to pure bug
> fixes...
> > > > although I suppose the difference between a "bug fix" and an
> > > "improvement"
> > > > is somewhat in the eye of the beholder.
> > > >
> > > > Ultimately, as long as there's a release covering these issues
> > > (everything
> > > > except the NIFI-2991[2] stuff) I don't particularly care what it's
> > > called.
> > > > If there are issues left out and I need to run a SNAPSHOT of some
> sort
> > to
> > > > get them, then a further 0.x release doesn't help me anyway, and I'll
> > > > withdraw my suggestion.
> > > >
> > > > Brandon
> > > >
> > > > [1]
> > > > <a href="https://issues.apache.org/jira/issues/?jql=project%20%">https://issues.apache.org/jira/issues/?jql=project%20%
> > > > 3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20and%
> > > > 20fixVersion%20not%20in%20(0.2.1%2C%200.3.0%2C%200.4.0%2C0.
> > > > 4.1%2C0.5.0%2C0.5.1%2C0.6.0%2C%200.6.1%2C0.7.0%2C%200.7.1%
> > > > 2C%200.7.2%2C%200.7.3)%20ORDER%20BY%20due%20ASC%2C%
> > 20priority%20DESC%2C%
> > > > 20created%20ASC
> > > >
> > > > [2] https://issues.apache.org/jira/browse/NIFI-2991
> > > >
> > > >
> > > > On Fri, Feb 24, 2017 at 7:49 PM Joe Witt <[hidden email]> wrote:
> > > >
> > > > > The 0.8 fixes for licensing remove a processor (gettwitter) at this
> > > > point.
> > > > > That I feel requires at least minor.  But avoiding that for now and
> > > doing
> > > > > the bug fix things and doing 073 seems legit.
> > > > >
> > > > > Will wait and see if anyone else has a different interpretation on
> > the
> > > > > intent of our one year version guidance and then update the wiki if
> > > > appears
> > > > > we have consensus.
> > > > >
> > > > > Thanks
> > > > > Joe
> > > > >
> > > > > On Feb 24, 2017 7:19 PM, "Andy LoPresto" <[hidden email]>
> > wrote:
> > > > >
> > > > > > Especially as nothing that would be going into the 0.x release
> is a
> > > > major
> > > > > > feature or changes compatibility (from my understanding), I would
> > +1
> > > > the
> > > > > > 0.7.3 suggestion.
> > > > > >
> > > > > > Andy LoPresto
> > > > > > [hidden email]
> > > > > > *[hidden email] <[hidden email]>*
> > > > > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D
> EF69
> > > > > >
> > > > > > On Feb 24, 2017, at 2:07 PM, Tony Kurc <[hidden email]> wrote:
> > > > > >
> > > > > > I think it is probably worth clarifying the intent of the support
> > > > > language.
> > > > > > I believe the intent was to support 0.x for a year after 1.x was
> > > > > released.
> > > > > > That was how I initially read the document you mentioned. But
> > after a
> > > > > > re-read, I'd echo your concerns about dragging old major lines
> > along.
> > > > > >
> > > > > > Tony
> > > > > >
> > > > > > On Fri, Feb 24, 2017 at 4:12 PM, Joe Witt <[hidden email]>
> > > wrote:
> > > > > >
> > > > > > Brandon,
> > > > > >
> > > > > > My concern is the language used when we published this "We
> support
> > > the
> > > > > > newest major release line (0.x, 1.x) and any previous major
> release
> > > > > > lines for up to one year since the last minor release (0.6.x,
> > 1.5.y)
> > > > > > in that line" within this document [1].
> > > > > >
> > > > > > If I read that now it seems like we're saying "if we make a minor
> > > > > > release we're going to support that for up to a year" and so each
> > > time
> > > > > > we create a new minor line on a given major line it means we are
> > > > > > resetting the clock.
> > > > > >
> > > > > > I do not believe we should give old major lines, such as 0.x, the
> > > > > > ability to drag on the community indefinitely as that reads.  I
> > > > > > believe it should be that we support a given major release line
> for
> > > up
> > > > > > to one year one after a new major release line is provided.
> > > > > >
> > > > > > So would like to hear peoples thoughts on that.
> > > > > >
> > > > > > If an 0.8 release is to occur the items called out are things
> which
> > > > > > impact licensing only (specifically the no longer allowed cat-x
> > json
> > > > > > library). I would be far more comfortable with 0.7.3 release
> which
> > > > > > would be fixing whatever bugs have been addressed.  That avoids
> the
> > > > > > concern I noted above for this case though i'd still like us to
> > > > > > clarify that language/intent anyway.
> > > > > >
> > > > > > Thanks
> > > > > > Joe
> > > > > >
> > > > > > On Fri, Feb 24, 2017 at 3:21 PM, Brandon DeVries <[hidden email]>
> > > wrote:
> > > > > >
> > > > > > Team,
> > > > > >
> > > > > > The only unresolved tickets against the 0.8.0 release[1] are for
> > the
> > > > > > removal of code...  With that in mind, does anyone object to
> trying
> > > to
> > > > > >
> > > > > > push
> > > > > >
> > > > > > for this (possibly final) 0.x release?
> > > > > >
> > > > > > Brandon
> > > > > >
> > > > > > [1]
> > > > > > <a href="https://issues.apache.org/jira/issues/?jql=project%20%">https://issues.apache.org/jira/issues/?jql=project%20%
> > > > > >
> > > > > > 3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20AND%
> > 20resolution%20%3D%
> > > > > > 20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%
> > > > > > 20DESC%2C%20created%20ASC
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Closing in on a NiFi 0.8.0 release?

Joe Witt
Mike

You are certainly more than welcome to give the RM role a go and it is
very appreciated particularly on 0.x where it isn't as easy to put
attention/cycles.

Thanks
Joe

On Wed, Apr 12, 2017 at 6:17 PM, Michael Moser <[hidden email]> wrote:

> All,
>
> I have started going through JIRA and identifying remaining issues against
> the 0.x branch to prepare for a release, and I've worked a couple of the
> JSON.org Cat-x license issues on that branch.
>
> I would like to volunteer to be release manager for a 0.7.3 release, if you
> will let me try.  ;-)
>
> -- Mike
>
>
> On Mon, Feb 27, 2017 at 10:55 AM, Joe Skora <[hidden email]> wrote:
>
>> Sorry for the confusion regarding 1.0.0-BETA vs 1.0.0, my bad.
>>
>> As for stability, I don't mean build and test stability but real world
>> stability feedback that has led to various repository fixes including the
>> 1.x line transition to the schema based provenance and newly refactored
>> provenance repository.
>>
>> Again, apologies for the beta confusion.
>>
>> On Mon, Feb 27, 2017 at 10:24 AM, Joe Witt <[hidden email]> wrote:
>>
>> > Joe
>> >
>> > 1.0.0 was not a beta release.
>> >
>> > 1.0.0-beta was a beta release.
>> >
>> > The intent of the language was we support the old major line for one year
>> > once there is a major release.  It is of course imperative to respect
>> that
>> > folks cannot migrate as quickly as we would always like.  But this sort
>> of
>> > concern is precisely why we have such a document.
>> >
>> > I propose we clarify the language to clearly and simply state that once a
>> > new major release line release has occurred we will support the old
>> release
>> > line for up to one year.   This does not distinguish between minor or
>> > incremental.  There is already language for that.
>> >
>> > The stability comment is an unclear line to debate.  The act of voting
>> on a
>> > release is the point at which the community agrees and asserts the
>> fitness
>> > of a release.  We have no other open and clear mechanism for doing so.
>> >
>> > I think the question of whether an 0.8 can happen is no longer tied to
>> the
>> > recent portions of this thread.  It would need am RM and vote.
>> >
>> > As I mentioned the other day I'll go ahead and update the versioning
>> > guidance barring any objection or alternative proposal.  I'll wait
>> another
>> > day or so in case you would like to propose alternative language for the
>> > commitment we make as a community to our users and ourselves.
>> >
>> > Thanks
>> > Joe
>> >
>> > On Feb 27, 2017 9:42 AM, "Joe Skora" <[hidden email]> wrote:
>> >
>> > > I think there's a couple considerations related to continuing the 0.x
>> > line.
>> > >
>> > > First, as JoeW mentioned the Release Line Management page [1] says we
>> > > support a major release for one year, so we should plan to support
>> 0.7.x
>> > > for one year from its July 13, 2016 release date [2].
>> > >
>> > > Also, since we considered the 1.0.0 release a beta [3], the 0.x line
>> was
>> > > due any fixes, features, and enhancements through the release of 1.1.0
>> on
>> > > November 30th.  So the features and fixes through November 30th should
>> be
>> > > backported where possible and appropriate and after that any fixes
>> > relating
>> > > to security or data loss should be backported for the life of the 0.x
>> > line.
>> > >
>> > > Next, I agree with JoeW that we don't want old lines to be a burden on
>> > the
>> > > community, but I suggest we consider the user base and how practical it
>> > is
>> > > to expect them to upgrade.  From 0.x to 1.x is a major transition, so I
>> > > think we should give more time for that transition than we will might
>> for
>> > > 1.1 to 1.2.
>> > >
>> > > Finally, 0.x only recently became stable for my users in the last
>> couple
>> > of
>> > > months, based on the 0.7.1 release with patches added for stability and
>> > > corruption issues that is similar to Brandon's list of outstanding 0.x
>> > > tickets.  Since the non-beta 1.1.0 release is less than 3 months old
>> and
>> > > the transition from 0.x to 1.x is so significant, regardless of our
>> > release
>> > > policy I would propose we carry on the 0.x line on until 1.x has
>> settled
>> > > and been shown to be similarly stable.
>> > >
>> > > Regards,
>> > > Joe
>> > >
>> > > [1]
>> > > https://cwiki.apache.org/confluence/display/NIFI/Git+
>> > > Branching+and+Release+Line+Management
>> > > [2]
>> > > https://lists.apache.org/thread.html/46678ade742887c624c14faf16d187
>> > > e039827121e35d08f468c3cbfe@%3Cdev.nifi.apache.org%3E
>> > > [3]
>> > > https://lists.apache.org/thread.html/91a4c272ddf2e80ec2fefd95c2a1df
>> > > 6c37689f4290aba5bdb81afd35@%3Cusers.nifi.apache.org%3E
>> > >
>> > >
>> > > On Fri, Feb 24, 2017 at 9:58 PM, Brandon DeVries <[hidden email]> wrote:
>> > >
>> > > > Based on Jira, there are 20 tickets marked as fixed in 0.8.0 and
>> > nowhere
>> > > > else in the 0.x line[1].  Highlights from these include:
>> > > >
>> > > >    - NIFI-2890 - Provenance Repository corruption
>> > > >    - NIFI-2920 - Swapped FlowFiles are not removed from content repo
>> > > when a
>> > > >    queue is emptied.
>> > > >    - NIFI-3055 - StandardRecordWriter can throw
>> UTFDataFormatException
>> > > >    - NIFI-3424 - CLONE for 0.x - Unable to generate Provenance Event
>> > > >    because FlowFile UUID is not set
>> > > >    - NIFI-3230 - Get/Put JMS broken for simple ActiveMQ SSL URIs
>> > > >    - NIFI-3403 - NPE in InvokeHTTP
>> > > >    - NIFI-3362 - Update FlowConfiguration.xsd TimePeriod to match
>> > > >    FormatUtils
>> > > >    - NIFI-2861 - ControlRate should accept more than one flow file
>> per
>> > > >    execution
>> > > >    - NIFI-3350 - Reduce NiFi startup time by streamlining
>> documentation
>> > > >    extraction
>> > > >
>> > > > Are we willing to port all of the tickets from [1] to the 0.7 branch?
>> > Or
>> > > > rather, which of them would not make the cut?  There are a couple of
>> > > things
>> > > > on the list that seem like new features as opposed to pure bug
>> fixes...
>> > > > although I suppose the difference between a "bug fix" and an
>> > > "improvement"
>> > > > is somewhat in the eye of the beholder.
>> > > >
>> > > > Ultimately, as long as there's a release covering these issues
>> > > (everything
>> > > > except the NIFI-2991[2] stuff) I don't particularly care what it's
>> > > called.
>> > > > If there are issues left out and I need to run a SNAPSHOT of some
>> sort
>> > to
>> > > > get them, then a further 0.x release doesn't help me anyway, and I'll
>> > > > withdraw my suggestion.
>> > > >
>> > > > Brandon
>> > > >
>> > > > [1]
>> > > > <a href="https://issues.apache.org/jira/issues/?jql=project%20%">https://issues.apache.org/jira/issues/?jql=project%20%
>> > > > 3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20and%
>> > > > 20fixVersion%20not%20in%20(0.2.1%2C%200.3.0%2C%200.4.0%2C0.
>> > > > 4.1%2C0.5.0%2C0.5.1%2C0.6.0%2C%200.6.1%2C0.7.0%2C%200.7.1%
>> > > > 2C%200.7.2%2C%200.7.3)%20ORDER%20BY%20due%20ASC%2C%
>> > 20priority%20DESC%2C%
>> > > > 20created%20ASC
>> > > >
>> > > > [2] https://issues.apache.org/jira/browse/NIFI-2991
>> > > >
>> > > >
>> > > > On Fri, Feb 24, 2017 at 7:49 PM Joe Witt <[hidden email]> wrote:
>> > > >
>> > > > > The 0.8 fixes for licensing remove a processor (gettwitter) at this
>> > > > point.
>> > > > > That I feel requires at least minor.  But avoiding that for now and
>> > > doing
>> > > > > the bug fix things and doing 073 seems legit.
>> > > > >
>> > > > > Will wait and see if anyone else has a different interpretation on
>> > the
>> > > > > intent of our one year version guidance and then update the wiki if
>> > > > appears
>> > > > > we have consensus.
>> > > > >
>> > > > > Thanks
>> > > > > Joe
>> > > > >
>> > > > > On Feb 24, 2017 7:19 PM, "Andy LoPresto" <[hidden email]>
>> > wrote:
>> > > > >
>> > > > > > Especially as nothing that would be going into the 0.x release
>> is a
>> > > > major
>> > > > > > feature or changes compatibility (from my understanding), I would
>> > +1
>> > > > the
>> > > > > > 0.7.3 suggestion.
>> > > > > >
>> > > > > > Andy LoPresto
>> > > > > > [hidden email]
>> > > > > > *[hidden email] <[hidden email]>*
>> > > > > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D
>> EF69
>> > > > > >
>> > > > > > On Feb 24, 2017, at 2:07 PM, Tony Kurc <[hidden email]> wrote:
>> > > > > >
>> > > > > > I think it is probably worth clarifying the intent of the support
>> > > > > language.
>> > > > > > I believe the intent was to support 0.x for a year after 1.x was
>> > > > > released.
>> > > > > > That was how I initially read the document you mentioned. But
>> > after a
>> > > > > > re-read, I'd echo your concerns about dragging old major lines
>> > along.
>> > > > > >
>> > > > > > Tony
>> > > > > >
>> > > > > > On Fri, Feb 24, 2017 at 4:12 PM, Joe Witt <[hidden email]>
>> > > wrote:
>> > > > > >
>> > > > > > Brandon,
>> > > > > >
>> > > > > > My concern is the language used when we published this "We
>> support
>> > > the
>> > > > > > newest major release line (0.x, 1.x) and any previous major
>> release
>> > > > > > lines for up to one year since the last minor release (0.6.x,
>> > 1.5.y)
>> > > > > > in that line" within this document [1].
>> > > > > >
>> > > > > > If I read that now it seems like we're saying "if we make a minor
>> > > > > > release we're going to support that for up to a year" and so each
>> > > time
>> > > > > > we create a new minor line on a given major line it means we are
>> > > > > > resetting the clock.
>> > > > > >
>> > > > > > I do not believe we should give old major lines, such as 0.x, the
>> > > > > > ability to drag on the community indefinitely as that reads.  I
>> > > > > > believe it should be that we support a given major release line
>> for
>> > > up
>> > > > > > to one year one after a new major release line is provided.
>> > > > > >
>> > > > > > So would like to hear peoples thoughts on that.
>> > > > > >
>> > > > > > If an 0.8 release is to occur the items called out are things
>> which
>> > > > > > impact licensing only (specifically the no longer allowed cat-x
>> > json
>> > > > > > library). I would be far more comfortable with 0.7.3 release
>> which
>> > > > > > would be fixing whatever bugs have been addressed.  That avoids
>> the
>> > > > > > concern I noted above for this case though i'd still like us to
>> > > > > > clarify that language/intent anyway.
>> > > > > >
>> > > > > > Thanks
>> > > > > > Joe
>> > > > > >
>> > > > > > On Fri, Feb 24, 2017 at 3:21 PM, Brandon DeVries <[hidden email]>
>> > > wrote:
>> > > > > >
>> > > > > > Team,
>> > > > > >
>> > > > > > The only unresolved tickets against the 0.8.0 release[1] are for
>> > the
>> > > > > > removal of code...  With that in mind, does anyone object to
>> trying
>> > > to
>> > > > > >
>> > > > > > push
>> > > > > >
>> > > > > > for this (possibly final) 0.x release?
>> > > > > >
>> > > > > > Brandon
>> > > > > >
>> > > > > > [1]
>> > > > > > <a href="https://issues.apache.org/jira/issues/?jql=project%20%">https://issues.apache.org/jira/issues/?jql=project%20%
>> > > > > >
>> > > > > > 3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20AND%
>> > 20resolution%20%3D%
>> > > > > > 20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%
>> > > > > > 20DESC%2C%20created%20ASC
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Closing in on a NiFi 0.8.0 release?

Michael Moser
I'll be starting to work through the release process for 0.7.3 over the
next several days, under this [1] JIRA.

-- Mike

[1] - https://issues.apache.org/jira/browse/NIFI-3824


On Sun, Apr 16, 2017 at 9:56 PM, Joe Witt <[hidden email]> wrote:

> Mike
>
> You are certainly more than welcome to give the RM role a go and it is
> very appreciated particularly on 0.x where it isn't as easy to put
> attention/cycles.
>
> Thanks
> Joe
>
> On Wed, Apr 12, 2017 at 6:17 PM, Michael Moser <[hidden email]> wrote:
> > All,
> >
> > I have started going through JIRA and identifying remaining issues
> against
> > the 0.x branch to prepare for a release, and I've worked a couple of the
> > JSON.org Cat-x license issues on that branch.
> >
> > I would like to volunteer to be release manager for a 0.7.3 release, if
> you
> > will let me try.  ;-)
> >
> > -- Mike
> >
> >
> > On Mon, Feb 27, 2017 at 10:55 AM, Joe Skora <[hidden email]> wrote:
> >
> >> Sorry for the confusion regarding 1.0.0-BETA vs 1.0.0, my bad.
> >>
> >> As for stability, I don't mean build and test stability but real world
> >> stability feedback that has led to various repository fixes including
> the
> >> 1.x line transition to the schema based provenance and newly refactored
> >> provenance repository.
> >>
> >> Again, apologies for the beta confusion.
> >>
> >> On Mon, Feb 27, 2017 at 10:24 AM, Joe Witt <[hidden email]> wrote:
> >>
> >> > Joe
> >> >
> >> > 1.0.0 was not a beta release.
> >> >
> >> > 1.0.0-beta was a beta release.
> >> >
> >> > The intent of the language was we support the old major line for one
> year
> >> > once there is a major release.  It is of course imperative to respect
> >> that
> >> > folks cannot migrate as quickly as we would always like.  But this
> sort
> >> of
> >> > concern is precisely why we have such a document.
> >> >
> >> > I propose we clarify the language to clearly and simply state that
> once a
> >> > new major release line release has occurred we will support the old
> >> release
> >> > line for up to one year.   This does not distinguish between minor or
> >> > incremental.  There is already language for that.
> >> >
> >> > The stability comment is an unclear line to debate.  The act of voting
> >> on a
> >> > release is the point at which the community agrees and asserts the
> >> fitness
> >> > of a release.  We have no other open and clear mechanism for doing so.
> >> >
> >> > I think the question of whether an 0.8 can happen is no longer tied to
> >> the
> >> > recent portions of this thread.  It would need am RM and vote.
> >> >
> >> > As I mentioned the other day I'll go ahead and update the versioning
> >> > guidance barring any objection or alternative proposal.  I'll wait
> >> another
> >> > day or so in case you would like to propose alternative language for
> the
> >> > commitment we make as a community to our users and ourselves.
> >> >
> >> > Thanks
> >> > Joe
> >> >
> >> > On Feb 27, 2017 9:42 AM, "Joe Skora" <[hidden email]> wrote:
> >> >
> >> > > I think there's a couple considerations related to continuing the
> 0.x
> >> > line.
> >> > >
> >> > > First, as JoeW mentioned the Release Line Management page [1] says
> we
> >> > > support a major release for one year, so we should plan to support
> >> 0.7.x
> >> > > for one year from its July 13, 2016 release date [2].
> >> > >
> >> > > Also, since we considered the 1.0.0 release a beta [3], the 0.x line
> >> was
> >> > > due any fixes, features, and enhancements through the release of
> 1.1.0
> >> on
> >> > > November 30th.  So the features and fixes through November 30th
> should
> >> be
> >> > > backported where possible and appropriate and after that any fixes
> >> > relating
> >> > > to security or data loss should be backported for the life of the
> 0.x
> >> > line.
> >> > >
> >> > > Next, I agree with JoeW that we don't want old lines to be a burden
> on
> >> > the
> >> > > community, but I suggest we consider the user base and how
> practical it
> >> > is
> >> > > to expect them to upgrade.  From 0.x to 1.x is a major transition,
> so I
> >> > > think we should give more time for that transition than we will
> might
> >> for
> >> > > 1.1 to 1.2.
> >> > >
> >> > > Finally, 0.x only recently became stable for my users in the last
> >> couple
> >> > of
> >> > > months, based on the 0.7.1 release with patches added for stability
> and
> >> > > corruption issues that is similar to Brandon's list of outstanding
> 0.x
> >> > > tickets.  Since the non-beta 1.1.0 release is less than 3 months old
> >> and
> >> > > the transition from 0.x to 1.x is so significant, regardless of our
> >> > release
> >> > > policy I would propose we carry on the 0.x line on until 1.x has
> >> settled
> >> > > and been shown to be similarly stable.
> >> > >
> >> > > Regards,
> >> > > Joe
> >> > >
> >> > > [1]
> >> > > https://cwiki.apache.org/confluence/display/NIFI/Git+
> >> > > Branching+and+Release+Line+Management
> >> > > [2]
> >> > > https://lists.apache.org/thread.html/46678ade742887c624c14faf16d187
> >> > > e039827121e35d08f468c3cbfe@%3Cdev.nifi.apache.org%3E
> >> > > [3]
> >> > > https://lists.apache.org/thread.html/91a4c272ddf2e80ec2fefd95c2a1df
> >> > > 6c37689f4290aba5bdb81afd35@%3Cusers.nifi.apache.org%3E
> >> > >
> >> > >
> >> > > On Fri, Feb 24, 2017 at 9:58 PM, Brandon DeVries <[hidden email]>
> wrote:
> >> > >
> >> > > > Based on Jira, there are 20 tickets marked as fixed in 0.8.0 and
> >> > nowhere
> >> > > > else in the 0.x line[1].  Highlights from these include:
> >> > > >
> >> > > >    - NIFI-2890 - Provenance Repository corruption
> >> > > >    - NIFI-2920 - Swapped FlowFiles are not removed from content
> repo
> >> > > when a
> >> > > >    queue is emptied.
> >> > > >    - NIFI-3055 - StandardRecordWriter can throw
> >> UTFDataFormatException
> >> > > >    - NIFI-3424 - CLONE for 0.x - Unable to generate Provenance
> Event
> >> > > >    because FlowFile UUID is not set
> >> > > >    - NIFI-3230 - Get/Put JMS broken for simple ActiveMQ SSL URIs
> >> > > >    - NIFI-3403 - NPE in InvokeHTTP
> >> > > >    - NIFI-3362 - Update FlowConfiguration.xsd TimePeriod to match
> >> > > >    FormatUtils
> >> > > >    - NIFI-2861 - ControlRate should accept more than one flow file
> >> per
> >> > > >    execution
> >> > > >    - NIFI-3350 - Reduce NiFi startup time by streamlining
> >> documentation
> >> > > >    extraction
> >> > > >
> >> > > > Are we willing to port all of the tickets from [1] to the 0.7
> branch?
> >> > Or
> >> > > > rather, which of them would not make the cut?  There are a couple
> of
> >> > > things
> >> > > > on the list that seem like new features as opposed to pure bug
> >> fixes...
> >> > > > although I suppose the difference between a "bug fix" and an
> >> > > "improvement"
> >> > > > is somewhat in the eye of the beholder.
> >> > > >
> >> > > > Ultimately, as long as there's a release covering these issues
> >> > > (everything
> >> > > > except the NIFI-2991[2] stuff) I don't particularly care what it's
> >> > > called.
> >> > > > If there are issues left out and I need to run a SNAPSHOT of some
> >> sort
> >> > to
> >> > > > get them, then a further 0.x release doesn't help me anyway, and
> I'll
> >> > > > withdraw my suggestion.
> >> > > >
> >> > > > Brandon
> >> > > >
> >> > > > [1]
> >> > > > <a href="https://issues.apache.org/jira/issues/?jql=project%20%">https://issues.apache.org/jira/issues/?jql=project%20%
> >> > > > 3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20and%
> >> > > > 20fixVersion%20not%20in%20(0.2.1%2C%200.3.0%2C%200.4.0%2C0.
> >> > > > 4.1%2C0.5.0%2C0.5.1%2C0.6.0%2C%200.6.1%2C0.7.0%2C%200.7.1%
> >> > > > 2C%200.7.2%2C%200.7.3)%20ORDER%20BY%20due%20ASC%2C%
> >> > 20priority%20DESC%2C%
> >> > > > 20created%20ASC
> >> > > >
> >> > > > [2] https://issues.apache.org/jira/browse/NIFI-2991
> >> > > >
> >> > > >
> >> > > > On Fri, Feb 24, 2017 at 7:49 PM Joe Witt <[hidden email]>
> wrote:
> >> > > >
> >> > > > > The 0.8 fixes for licensing remove a processor (gettwitter) at
> this
> >> > > > point.
> >> > > > > That I feel requires at least minor.  But avoiding that for now
> and
> >> > > doing
> >> > > > > the bug fix things and doing 073 seems legit.
> >> > > > >
> >> > > > > Will wait and see if anyone else has a different interpretation
> on
> >> > the
> >> > > > > intent of our one year version guidance and then update the
> wiki if
> >> > > > appears
> >> > > > > we have consensus.
> >> > > > >
> >> > > > > Thanks
> >> > > > > Joe
> >> > > > >
> >> > > > > On Feb 24, 2017 7:19 PM, "Andy LoPresto" <[hidden email]>
> >> > wrote:
> >> > > > >
> >> > > > > > Especially as nothing that would be going into the 0.x release
> >> is a
> >> > > > major
> >> > > > > > feature or changes compatibility (from my understanding), I
> would
> >> > +1
> >> > > > the
> >> > > > > > 0.7.3 suggestion.
> >> > > > > >
> >> > > > > > Andy LoPresto
> >> > > > > > [hidden email]
> >> > > > > > *[hidden email] <[hidden email]>*
> >> > > > > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D
> >> EF69
> >> > > > > >
> >> > > > > > On Feb 24, 2017, at 2:07 PM, Tony Kurc <[hidden email]>
> wrote:
> >> > > > > >
> >> > > > > > I think it is probably worth clarifying the intent of the
> support
> >> > > > > language.
> >> > > > > > I believe the intent was to support 0.x for a year after 1.x
> was
> >> > > > > released.
> >> > > > > > That was how I initially read the document you mentioned. But
> >> > after a
> >> > > > > > re-read, I'd echo your concerns about dragging old major lines
> >> > along.
> >> > > > > >
> >> > > > > > Tony
> >> > > > > >
> >> > > > > > On Fri, Feb 24, 2017 at 4:12 PM, Joe Witt <[hidden email]
> >
> >> > > wrote:
> >> > > > > >
> >> > > > > > Brandon,
> >> > > > > >
> >> > > > > > My concern is the language used when we published this "We
> >> support
> >> > > the
> >> > > > > > newest major release line (0.x, 1.x) and any previous major
> >> release
> >> > > > > > lines for up to one year since the last minor release (0.6.x,
> >> > 1.5.y)
> >> > > > > > in that line" within this document [1].
> >> > > > > >
> >> > > > > > If I read that now it seems like we're saying "if we make a
> minor
> >> > > > > > release we're going to support that for up to a year" and so
> each
> >> > > time
> >> > > > > > we create a new minor line on a given major line it means we
> are
> >> > > > > > resetting the clock.
> >> > > > > >
> >> > > > > > I do not believe we should give old major lines, such as 0.x,
> the
> >> > > > > > ability to drag on the community indefinitely as that reads.
> I
> >> > > > > > believe it should be that we support a given major release
> line
> >> for
> >> > > up
> >> > > > > > to one year one after a new major release line is provided.
> >> > > > > >
> >> > > > > > So would like to hear peoples thoughts on that.
> >> > > > > >
> >> > > > > > If an 0.8 release is to occur the items called out are things
> >> which
> >> > > > > > impact licensing only (specifically the no longer allowed
> cat-x
> >> > json
> >> > > > > > library). I would be far more comfortable with 0.7.3 release
> >> which
> >> > > > > > would be fixing whatever bugs have been addressed.  That
> avoids
> >> the
> >> > > > > > concern I noted above for this case though i'd still like us
> to
> >> > > > > > clarify that language/intent anyway.
> >> > > > > >
> >> > > > > > Thanks
> >> > > > > > Joe
> >> > > > > >
> >> > > > > > On Fri, Feb 24, 2017 at 3:21 PM, Brandon DeVries <[hidden email]
> >
> >> > > wrote:
> >> > > > > >
> >> > > > > > Team,
> >> > > > > >
> >> > > > > > The only unresolved tickets against the 0.8.0 release[1] are
> for
> >> > the
> >> > > > > > removal of code...  With that in mind, does anyone object to
> >> trying
> >> > > to
> >> > > > > >
> >> > > > > > push
> >> > > > > >
> >> > > > > > for this (possibly final) 0.x release?
> >> > > > > >
> >> > > > > > Brandon
> >> > > > > >
> >> > > > > > [1]
> >> > > > > > <a href="https://issues.apache.org/jira/issues/?jql=project%20%">https://issues.apache.org/jira/issues/?jql=project%20%
> >> > > > > >
> >> > > > > > 3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20AND%
> >> > 20resolution%20%3D%
> >> > > > > > 20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%
> >> > > > > > 20DESC%2C%20created%20ASC
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Closing in on a NiFi 0.8.0 release?

Joe Witt
Mike

it looks like there is only a single 0.7.3 ticket but there are a lot
of 0.8.0 tickets.  Are you planning to cherry-pick the needed commits
into the support/0.7.x branch?

Thanks
Joe

On Thu, May 11, 2017 at 1:55 PM, Michael Moser <[hidden email]> wrote:

> I'll be starting to work through the release process for 0.7.3 over the
> next several days, under this [1] JIRA.
>
> -- Mike
>
> [1] - https://issues.apache.org/jira/browse/NIFI-3824
>
>
> On Sun, Apr 16, 2017 at 9:56 PM, Joe Witt <[hidden email]> wrote:
>
>> Mike
>>
>> You are certainly more than welcome to give the RM role a go and it is
>> very appreciated particularly on 0.x where it isn't as easy to put
>> attention/cycles.
>>
>> Thanks
>> Joe
>>
>> On Wed, Apr 12, 2017 at 6:17 PM, Michael Moser <[hidden email]> wrote:
>> > All,
>> >
>> > I have started going through JIRA and identifying remaining issues
>> against
>> > the 0.x branch to prepare for a release, and I've worked a couple of the
>> > JSON.org Cat-x license issues on that branch.
>> >
>> > I would like to volunteer to be release manager for a 0.7.3 release, if
>> you
>> > will let me try.  ;-)
>> >
>> > -- Mike
>> >
>> >
>> > On Mon, Feb 27, 2017 at 10:55 AM, Joe Skora <[hidden email]> wrote:
>> >
>> >> Sorry for the confusion regarding 1.0.0-BETA vs 1.0.0, my bad.
>> >>
>> >> As for stability, I don't mean build and test stability but real world
>> >> stability feedback that has led to various repository fixes including
>> the
>> >> 1.x line transition to the schema based provenance and newly refactored
>> >> provenance repository.
>> >>
>> >> Again, apologies for the beta confusion.
>> >>
>> >> On Mon, Feb 27, 2017 at 10:24 AM, Joe Witt <[hidden email]> wrote:
>> >>
>> >> > Joe
>> >> >
>> >> > 1.0.0 was not a beta release.
>> >> >
>> >> > 1.0.0-beta was a beta release.
>> >> >
>> >> > The intent of the language was we support the old major line for one
>> year
>> >> > once there is a major release.  It is of course imperative to respect
>> >> that
>> >> > folks cannot migrate as quickly as we would always like.  But this
>> sort
>> >> of
>> >> > concern is precisely why we have such a document.
>> >> >
>> >> > I propose we clarify the language to clearly and simply state that
>> once a
>> >> > new major release line release has occurred we will support the old
>> >> release
>> >> > line for up to one year.   This does not distinguish between minor or
>> >> > incremental.  There is already language for that.
>> >> >
>> >> > The stability comment is an unclear line to debate.  The act of voting
>> >> on a
>> >> > release is the point at which the community agrees and asserts the
>> >> fitness
>> >> > of a release.  We have no other open and clear mechanism for doing so.
>> >> >
>> >> > I think the question of whether an 0.8 can happen is no longer tied to
>> >> the
>> >> > recent portions of this thread.  It would need am RM and vote.
>> >> >
>> >> > As I mentioned the other day I'll go ahead and update the versioning
>> >> > guidance barring any objection or alternative proposal.  I'll wait
>> >> another
>> >> > day or so in case you would like to propose alternative language for
>> the
>> >> > commitment we make as a community to our users and ourselves.
>> >> >
>> >> > Thanks
>> >> > Joe
>> >> >
>> >> > On Feb 27, 2017 9:42 AM, "Joe Skora" <[hidden email]> wrote:
>> >> >
>> >> > > I think there's a couple considerations related to continuing the
>> 0.x
>> >> > line.
>> >> > >
>> >> > > First, as JoeW mentioned the Release Line Management page [1] says
>> we
>> >> > > support a major release for one year, so we should plan to support
>> >> 0.7.x
>> >> > > for one year from its July 13, 2016 release date [2].
>> >> > >
>> >> > > Also, since we considered the 1.0.0 release a beta [3], the 0.x line
>> >> was
>> >> > > due any fixes, features, and enhancements through the release of
>> 1.1.0
>> >> on
>> >> > > November 30th.  So the features and fixes through November 30th
>> should
>> >> be
>> >> > > backported where possible and appropriate and after that any fixes
>> >> > relating
>> >> > > to security or data loss should be backported for the life of the
>> 0.x
>> >> > line.
>> >> > >
>> >> > > Next, I agree with JoeW that we don't want old lines to be a burden
>> on
>> >> > the
>> >> > > community, but I suggest we consider the user base and how
>> practical it
>> >> > is
>> >> > > to expect them to upgrade.  From 0.x to 1.x is a major transition,
>> so I
>> >> > > think we should give more time for that transition than we will
>> might
>> >> for
>> >> > > 1.1 to 1.2.
>> >> > >
>> >> > > Finally, 0.x only recently became stable for my users in the last
>> >> couple
>> >> > of
>> >> > > months, based on the 0.7.1 release with patches added for stability
>> and
>> >> > > corruption issues that is similar to Brandon's list of outstanding
>> 0.x
>> >> > > tickets.  Since the non-beta 1.1.0 release is less than 3 months old
>> >> and
>> >> > > the transition from 0.x to 1.x is so significant, regardless of our
>> >> > release
>> >> > > policy I would propose we carry on the 0.x line on until 1.x has
>> >> settled
>> >> > > and been shown to be similarly stable.
>> >> > >
>> >> > > Regards,
>> >> > > Joe
>> >> > >
>> >> > > [1]
>> >> > > https://cwiki.apache.org/confluence/display/NIFI/Git+
>> >> > > Branching+and+Release+Line+Management
>> >> > > [2]
>> >> > > https://lists.apache.org/thread.html/46678ade742887c624c14faf16d187
>> >> > > e039827121e35d08f468c3cbfe@%3Cdev.nifi.apache.org%3E
>> >> > > [3]
>> >> > > https://lists.apache.org/thread.html/91a4c272ddf2e80ec2fefd95c2a1df
>> >> > > 6c37689f4290aba5bdb81afd35@%3Cusers.nifi.apache.org%3E
>> >> > >
>> >> > >
>> >> > > On Fri, Feb 24, 2017 at 9:58 PM, Brandon DeVries <[hidden email]>
>> wrote:
>> >> > >
>> >> > > > Based on Jira, there are 20 tickets marked as fixed in 0.8.0 and
>> >> > nowhere
>> >> > > > else in the 0.x line[1].  Highlights from these include:
>> >> > > >
>> >> > > >    - NIFI-2890 - Provenance Repository corruption
>> >> > > >    - NIFI-2920 - Swapped FlowFiles are not removed from content
>> repo
>> >> > > when a
>> >> > > >    queue is emptied.
>> >> > > >    - NIFI-3055 - StandardRecordWriter can throw
>> >> UTFDataFormatException
>> >> > > >    - NIFI-3424 - CLONE for 0.x - Unable to generate Provenance
>> Event
>> >> > > >    because FlowFile UUID is not set
>> >> > > >    - NIFI-3230 - Get/Put JMS broken for simple ActiveMQ SSL URIs
>> >> > > >    - NIFI-3403 - NPE in InvokeHTTP
>> >> > > >    - NIFI-3362 - Update FlowConfiguration.xsd TimePeriod to match
>> >> > > >    FormatUtils
>> >> > > >    - NIFI-2861 - ControlRate should accept more than one flow file
>> >> per
>> >> > > >    execution
>> >> > > >    - NIFI-3350 - Reduce NiFi startup time by streamlining
>> >> documentation
>> >> > > >    extraction
>> >> > > >
>> >> > > > Are we willing to port all of the tickets from [1] to the 0.7
>> branch?
>> >> > Or
>> >> > > > rather, which of them would not make the cut?  There are a couple
>> of
>> >> > > things
>> >> > > > on the list that seem like new features as opposed to pure bug
>> >> fixes...
>> >> > > > although I suppose the difference between a "bug fix" and an
>> >> > > "improvement"
>> >> > > > is somewhat in the eye of the beholder.
>> >> > > >
>> >> > > > Ultimately, as long as there's a release covering these issues
>> >> > > (everything
>> >> > > > except the NIFI-2991[2] stuff) I don't particularly care what it's
>> >> > > called.
>> >> > > > If there are issues left out and I need to run a SNAPSHOT of some
>> >> sort
>> >> > to
>> >> > > > get them, then a further 0.x release doesn't help me anyway, and
>> I'll
>> >> > > > withdraw my suggestion.
>> >> > > >
>> >> > > > Brandon
>> >> > > >
>> >> > > > [1]
>> >> > > > <a href="https://issues.apache.org/jira/issues/?jql=project%20%">https://issues.apache.org/jira/issues/?jql=project%20%
>> >> > > > 3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20and%
>> >> > > > 20fixVersion%20not%20in%20(0.2.1%2C%200.3.0%2C%200.4.0%2C0.
>> >> > > > 4.1%2C0.5.0%2C0.5.1%2C0.6.0%2C%200.6.1%2C0.7.0%2C%200.7.1%
>> >> > > > 2C%200.7.2%2C%200.7.3)%20ORDER%20BY%20due%20ASC%2C%
>> >> > 20priority%20DESC%2C%
>> >> > > > 20created%20ASC
>> >> > > >
>> >> > > > [2] https://issues.apache.org/jira/browse/NIFI-2991
>> >> > > >
>> >> > > >
>> >> > > > On Fri, Feb 24, 2017 at 7:49 PM Joe Witt <[hidden email]>
>> wrote:
>> >> > > >
>> >> > > > > The 0.8 fixes for licensing remove a processor (gettwitter) at
>> this
>> >> > > > point.
>> >> > > > > That I feel requires at least minor.  But avoiding that for now
>> and
>> >> > > doing
>> >> > > > > the bug fix things and doing 073 seems legit.
>> >> > > > >
>> >> > > > > Will wait and see if anyone else has a different interpretation
>> on
>> >> > the
>> >> > > > > intent of our one year version guidance and then update the
>> wiki if
>> >> > > > appears
>> >> > > > > we have consensus.
>> >> > > > >
>> >> > > > > Thanks
>> >> > > > > Joe
>> >> > > > >
>> >> > > > > On Feb 24, 2017 7:19 PM, "Andy LoPresto" <[hidden email]>
>> >> > wrote:
>> >> > > > >
>> >> > > > > > Especially as nothing that would be going into the 0.x release
>> >> is a
>> >> > > > major
>> >> > > > > > feature or changes compatibility (from my understanding), I
>> would
>> >> > +1
>> >> > > > the
>> >> > > > > > 0.7.3 suggestion.
>> >> > > > > >
>> >> > > > > > Andy LoPresto
>> >> > > > > > [hidden email]
>> >> > > > > > *[hidden email] <[hidden email]>*
>> >> > > > > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D
>> >> EF69
>> >> > > > > >
>> >> > > > > > On Feb 24, 2017, at 2:07 PM, Tony Kurc <[hidden email]>
>> wrote:
>> >> > > > > >
>> >> > > > > > I think it is probably worth clarifying the intent of the
>> support
>> >> > > > > language.
>> >> > > > > > I believe the intent was to support 0.x for a year after 1.x
>> was
>> >> > > > > released.
>> >> > > > > > That was how I initially read the document you mentioned. But
>> >> > after a
>> >> > > > > > re-read, I'd echo your concerns about dragging old major lines
>> >> > along.
>> >> > > > > >
>> >> > > > > > Tony
>> >> > > > > >
>> >> > > > > > On Fri, Feb 24, 2017 at 4:12 PM, Joe Witt <[hidden email]
>> >
>> >> > > wrote:
>> >> > > > > >
>> >> > > > > > Brandon,
>> >> > > > > >
>> >> > > > > > My concern is the language used when we published this "We
>> >> support
>> >> > > the
>> >> > > > > > newest major release line (0.x, 1.x) and any previous major
>> >> release
>> >> > > > > > lines for up to one year since the last minor release (0.6.x,
>> >> > 1.5.y)
>> >> > > > > > in that line" within this document [1].
>> >> > > > > >
>> >> > > > > > If I read that now it seems like we're saying "if we make a
>> minor
>> >> > > > > > release we're going to support that for up to a year" and so
>> each
>> >> > > time
>> >> > > > > > we create a new minor line on a given major line it means we
>> are
>> >> > > > > > resetting the clock.
>> >> > > > > >
>> >> > > > > > I do not believe we should give old major lines, such as 0.x,
>> the
>> >> > > > > > ability to drag on the community indefinitely as that reads.
>> I
>> >> > > > > > believe it should be that we support a given major release
>> line
>> >> for
>> >> > > up
>> >> > > > > > to one year one after a new major release line is provided.
>> >> > > > > >
>> >> > > > > > So would like to hear peoples thoughts on that.
>> >> > > > > >
>> >> > > > > > If an 0.8 release is to occur the items called out are things
>> >> which
>> >> > > > > > impact licensing only (specifically the no longer allowed
>> cat-x
>> >> > json
>> >> > > > > > library). I would be far more comfortable with 0.7.3 release
>> >> which
>> >> > > > > > would be fixing whatever bugs have been addressed.  That
>> avoids
>> >> the
>> >> > > > > > concern I noted above for this case though i'd still like us
>> to
>> >> > > > > > clarify that language/intent anyway.
>> >> > > > > >
>> >> > > > > > Thanks
>> >> > > > > > Joe
>> >> > > > > >
>> >> > > > > > On Fri, Feb 24, 2017 at 3:21 PM, Brandon DeVries <[hidden email]
>> >
>> >> > > wrote:
>> >> > > > > >
>> >> > > > > > Team,
>> >> > > > > >
>> >> > > > > > The only unresolved tickets against the 0.8.0 release[1] are
>> for
>> >> > the
>> >> > > > > > removal of code...  With that in mind, does anyone object to
>> >> trying
>> >> > > to
>> >> > > > > >
>> >> > > > > > push
>> >> > > > > >
>> >> > > > > > for this (possibly final) 0.x release?
>> >> > > > > >
>> >> > > > > > Brandon
>> >> > > > > >
>> >> > > > > > [1]
>> >> > > > > > <a href="https://issues.apache.org/jira/issues/?jql=project%20%">https://issues.apache.org/jira/issues/?jql=project%20%
>> >> > > > > >
>> >> > > > > > 3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20AND%
>> >> > 20resolution%20%3D%
>> >> > > > > > 20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%
>> >> > > > > > 20DESC%2C%20created%20ASC
>> >> > > > > >
>> >> > > > > >
>> >> > > > > >
>> >> > > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Closing in on a NiFi 0.8.0 release?

Michael Moser
Yes indeed, I finished merging the necessary commits from 0.x into the
support/0.7.x branch.  I also added the 0.7.3 Fix Version to the JIRA
tickets that were affected.  I should have learned by now to do this before
sending email, haha.

Regards,
-- Mike


On Thu, May 11, 2017 at 1:57 PM, Joe Witt <[hidden email]> wrote:

> Mike
>
> it looks like there is only a single 0.7.3 ticket but there are a lot
> of 0.8.0 tickets.  Are you planning to cherry-pick the needed commits
> into the support/0.7.x branch?
>
> Thanks
> Joe
>
> On Thu, May 11, 2017 at 1:55 PM, Michael Moser <[hidden email]> wrote:
> > I'll be starting to work through the release process for 0.7.3 over the
> > next several days, under this [1] JIRA.
> >
> > -- Mike
> >
> > [1] - https://issues.apache.org/jira/browse/NIFI-3824
> >
> >
> > On Sun, Apr 16, 2017 at 9:56 PM, Joe Witt <[hidden email]> wrote:
> >
> >> Mike
> >>
> >> You are certainly more than welcome to give the RM role a go and it is
> >> very appreciated particularly on 0.x where it isn't as easy to put
> >> attention/cycles.
> >>
> >> Thanks
> >> Joe
> >>
> >> On Wed, Apr 12, 2017 at 6:17 PM, Michael Moser <[hidden email]>
> wrote:
> >> > All,
> >> >
> >> > I have started going through JIRA and identifying remaining issues
> >> against
> >> > the 0.x branch to prepare for a release, and I've worked a couple of
> the
> >> > JSON.org Cat-x license issues on that branch.
> >> >
> >> > I would like to volunteer to be release manager for a 0.7.3 release,
> if
> >> you
> >> > will let me try.  ;-)
> >> >
> >> > -- Mike
> >> >
> >> >
> >> > On Mon, Feb 27, 2017 at 10:55 AM, Joe Skora <[hidden email]> wrote:
> >> >
> >> >> Sorry for the confusion regarding 1.0.0-BETA vs 1.0.0, my bad.
> >> >>
> >> >> As for stability, I don't mean build and test stability but real
> world
> >> >> stability feedback that has led to various repository fixes including
> >> the
> >> >> 1.x line transition to the schema based provenance and newly
> refactored
> >> >> provenance repository.
> >> >>
> >> >> Again, apologies for the beta confusion.
> >> >>
> >> >> On Mon, Feb 27, 2017 at 10:24 AM, Joe Witt <[hidden email]>
> wrote:
> >> >>
> >> >> > Joe
> >> >> >
> >> >> > 1.0.0 was not a beta release.
> >> >> >
> >> >> > 1.0.0-beta was a beta release.
> >> >> >
> >> >> > The intent of the language was we support the old major line for
> one
> >> year
> >> >> > once there is a major release.  It is of course imperative to
> respect
> >> >> that
> >> >> > folks cannot migrate as quickly as we would always like.  But this
> >> sort
> >> >> of
> >> >> > concern is precisely why we have such a document.
> >> >> >
> >> >> > I propose we clarify the language to clearly and simply state that
> >> once a
> >> >> > new major release line release has occurred we will support the old
> >> >> release
> >> >> > line for up to one year.   This does not distinguish between minor
> or
> >> >> > incremental.  There is already language for that.
> >> >> >
> >> >> > The stability comment is an unclear line to debate.  The act of
> voting
> >> >> on a
> >> >> > release is the point at which the community agrees and asserts the
> >> >> fitness
> >> >> > of a release.  We have no other open and clear mechanism for doing
> so.
> >> >> >
> >> >> > I think the question of whether an 0.8 can happen is no longer
> tied to
> >> >> the
> >> >> > recent portions of this thread.  It would need am RM and vote.
> >> >> >
> >> >> > As I mentioned the other day I'll go ahead and update the
> versioning
> >> >> > guidance barring any objection or alternative proposal.  I'll wait
> >> >> another
> >> >> > day or so in case you would like to propose alternative language
> for
> >> the
> >> >> > commitment we make as a community to our users and ourselves.
> >> >> >
> >> >> > Thanks
> >> >> > Joe
> >> >> >
> >> >> > On Feb 27, 2017 9:42 AM, "Joe Skora" <[hidden email]> wrote:
> >> >> >
> >> >> > > I think there's a couple considerations related to continuing the
> >> 0.x
> >> >> > line.
> >> >> > >
> >> >> > > First, as JoeW mentioned the Release Line Management page [1]
> says
> >> we
> >> >> > > support a major release for one year, so we should plan to
> support
> >> >> 0.7.x
> >> >> > > for one year from its July 13, 2016 release date [2].
> >> >> > >
> >> >> > > Also, since we considered the 1.0.0 release a beta [3], the 0.x
> line
> >> >> was
> >> >> > > due any fixes, features, and enhancements through the release of
> >> 1.1.0
> >> >> on
> >> >> > > November 30th.  So the features and fixes through November 30th
> >> should
> >> >> be
> >> >> > > backported where possible and appropriate and after that any
> fixes
> >> >> > relating
> >> >> > > to security or data loss should be backported for the life of the
> >> 0.x
> >> >> > line.
> >> >> > >
> >> >> > > Next, I agree with JoeW that we don't want old lines to be a
> burden
> >> on
> >> >> > the
> >> >> > > community, but I suggest we consider the user base and how
> >> practical it
> >> >> > is
> >> >> > > to expect them to upgrade.  From 0.x to 1.x is a major
> transition,
> >> so I
> >> >> > > think we should give more time for that transition than we will
> >> might
> >> >> for
> >> >> > > 1.1 to 1.2.
> >> >> > >
> >> >> > > Finally, 0.x only recently became stable for my users in the last
> >> >> couple
> >> >> > of
> >> >> > > months, based on the 0.7.1 release with patches added for
> stability
> >> and
> >> >> > > corruption issues that is similar to Brandon's list of
> outstanding
> >> 0.x
> >> >> > > tickets.  Since the non-beta 1.1.0 release is less than 3 months
> old
> >> >> and
> >> >> > > the transition from 0.x to 1.x is so significant, regardless of
> our
> >> >> > release
> >> >> > > policy I would propose we carry on the 0.x line on until 1.x has
> >> >> settled
> >> >> > > and been shown to be similarly stable.
> >> >> > >
> >> >> > > Regards,
> >> >> > > Joe
> >> >> > >
> >> >> > > [1]
> >> >> > > https://cwiki.apache.org/confluence/display/NIFI/Git+
> >> >> > > Branching+and+Release+Line+Management
> >> >> > > [2]
> >> >> > > https://lists.apache.org/thread.html/
> 46678ade742887c624c14faf16d187
> >> >> > > e039827121e35d08f468c3cbfe@%3Cdev.nifi.apache.org%3E
> >> >> > > [3]
> >> >> > > https://lists.apache.org/thread.html/
> 91a4c272ddf2e80ec2fefd95c2a1df
> >> >> > > 6c37689f4290aba5bdb81afd35@%3Cusers.nifi.apache.org%3E
> >> >> > >
> >> >> > >
> >> >> > > On Fri, Feb 24, 2017 at 9:58 PM, Brandon DeVries <[hidden email]>
> >> wrote:
> >> >> > >
> >> >> > > > Based on Jira, there are 20 tickets marked as fixed in 0.8.0
> and
> >> >> > nowhere
> >> >> > > > else in the 0.x line[1].  Highlights from these include:
> >> >> > > >
> >> >> > > >    - NIFI-2890 - Provenance Repository corruption
> >> >> > > >    - NIFI-2920 - Swapped FlowFiles are not removed from content
> >> repo
> >> >> > > when a
> >> >> > > >    queue is emptied.
> >> >> > > >    - NIFI-3055 - StandardRecordWriter can throw
> >> >> UTFDataFormatException
> >> >> > > >    - NIFI-3424 - CLONE for 0.x - Unable to generate Provenance
> >> Event
> >> >> > > >    because FlowFile UUID is not set
> >> >> > > >    - NIFI-3230 - Get/Put JMS broken for simple ActiveMQ SSL
> URIs
> >> >> > > >    - NIFI-3403 - NPE in InvokeHTTP
> >> >> > > >    - NIFI-3362 - Update FlowConfiguration.xsd TimePeriod to
> match
> >> >> > > >    FormatUtils
> >> >> > > >    - NIFI-2861 - ControlRate should accept more than one flow
> file
> >> >> per
> >> >> > > >    execution
> >> >> > > >    - NIFI-3350 - Reduce NiFi startup time by streamlining
> >> >> documentation
> >> >> > > >    extraction
> >> >> > > >
> >> >> > > > Are we willing to port all of the tickets from [1] to the 0.7
> >> branch?
> >> >> > Or
> >> >> > > > rather, which of them would not make the cut?  There are a
> couple
> >> of
> >> >> > > things
> >> >> > > > on the list that seem like new features as opposed to pure bug
> >> >> fixes...
> >> >> > > > although I suppose the difference between a "bug fix" and an
> >> >> > > "improvement"
> >> >> > > > is somewhat in the eye of the beholder.
> >> >> > > >
> >> >> > > > Ultimately, as long as there's a release covering these issues
> >> >> > > (everything
> >> >> > > > except the NIFI-2991[2] stuff) I don't particularly care what
> it's
> >> >> > > called.
> >> >> > > > If there are issues left out and I need to run a SNAPSHOT of
> some
> >> >> sort
> >> >> > to
> >> >> > > > get them, then a further 0.x release doesn't help me anyway,
> and
> >> I'll
> >> >> > > > withdraw my suggestion.
> >> >> > > >
> >> >> > > > Brandon
> >> >> > > >
> >> >> > > > [1]
> >> >> > > > <a href="https://issues.apache.org/jira/issues/?jql=project%20%">https://issues.apache.org/jira/issues/?jql=project%20%
> >> >> > > > 3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20and%
> >> >> > > > 20fixVersion%20not%20in%20(0.2.1%2C%200.3.0%2C%200.4.0%2C0.
> >> >> > > > 4.1%2C0.5.0%2C0.5.1%2C0.6.0%2C%200.6.1%2C0.7.0%2C%200.7.1%
> >> >> > > > 2C%200.7.2%2C%200.7.3)%20ORDER%20BY%20due%20ASC%2C%
> >> >> > 20priority%20DESC%2C%
> >> >> > > > 20created%20ASC
> >> >> > > >
> >> >> > > > [2] https://issues.apache.org/jira/browse/NIFI-2991
> >> >> > > >
> >> >> > > >
> >> >> > > > On Fri, Feb 24, 2017 at 7:49 PM Joe Witt <[hidden email]>
> >> wrote:
> >> >> > > >
> >> >> > > > > The 0.8 fixes for licensing remove a processor (gettwitter)
> at
> >> this
> >> >> > > > point.
> >> >> > > > > That I feel requires at least minor.  But avoiding that for
> now
> >> and
> >> >> > > doing
> >> >> > > > > the bug fix things and doing 073 seems legit.
> >> >> > > > >
> >> >> > > > > Will wait and see if anyone else has a different
> interpretation
> >> on
> >> >> > the
> >> >> > > > > intent of our one year version guidance and then update the
> >> wiki if
> >> >> > > > appears
> >> >> > > > > we have consensus.
> >> >> > > > >
> >> >> > > > > Thanks
> >> >> > > > > Joe
> >> >> > > > >
> >> >> > > > > On Feb 24, 2017 7:19 PM, "Andy LoPresto" <
> [hidden email]>
> >> >> > wrote:
> >> >> > > > >
> >> >> > > > > > Especially as nothing that would be going into the 0.x
> release
> >> >> is a
> >> >> > > > major
> >> >> > > > > > feature or changes compatibility (from my understanding), I
> >> would
> >> >> > +1
> >> >> > > > the
> >> >> > > > > > 0.7.3 suggestion.
> >> >> > > > > >
> >> >> > > > > > Andy LoPresto
> >> >> > > > > > [hidden email]
> >> >> > > > > > *[hidden email] <[hidden email]>*
> >> >> > > > > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B
> 2F7D
> >> >> EF69
> >> >> > > > > >
> >> >> > > > > > On Feb 24, 2017, at 2:07 PM, Tony Kurc <[hidden email]>
> >> wrote:
> >> >> > > > > >
> >> >> > > > > > I think it is probably worth clarifying the intent of the
> >> support
> >> >> > > > > language.
> >> >> > > > > > I believe the intent was to support 0.x for a year after
> 1.x
> >> was
> >> >> > > > > released.
> >> >> > > > > > That was how I initially read the document you mentioned.
> But
> >> >> > after a
> >> >> > > > > > re-read, I'd echo your concerns about dragging old major
> lines
> >> >> > along.
> >> >> > > > > >
> >> >> > > > > > Tony
> >> >> > > > > >
> >> >> > > > > > On Fri, Feb 24, 2017 at 4:12 PM, Joe Witt <
> [hidden email]
> >> >
> >> >> > > wrote:
> >> >> > > > > >
> >> >> > > > > > Brandon,
> >> >> > > > > >
> >> >> > > > > > My concern is the language used when we published this "We
> >> >> support
> >> >> > > the
> >> >> > > > > > newest major release line (0.x, 1.x) and any previous major
> >> >> release
> >> >> > > > > > lines for up to one year since the last minor release
> (0.6.x,
> >> >> > 1.5.y)
> >> >> > > > > > in that line" within this document [1].
> >> >> > > > > >
> >> >> > > > > > If I read that now it seems like we're saying "if we make a
> >> minor
> >> >> > > > > > release we're going to support that for up to a year" and
> so
> >> each
> >> >> > > time
> >> >> > > > > > we create a new minor line on a given major line it means
> we
> >> are
> >> >> > > > > > resetting the clock.
> >> >> > > > > >
> >> >> > > > > > I do not believe we should give old major lines, such as
> 0.x,
> >> the
> >> >> > > > > > ability to drag on the community indefinitely as that
> reads.
> >> I
> >> >> > > > > > believe it should be that we support a given major release
> >> line
> >> >> for
> >> >> > > up
> >> >> > > > > > to one year one after a new major release line is provided.
> >> >> > > > > >
> >> >> > > > > > So would like to hear peoples thoughts on that.
> >> >> > > > > >
> >> >> > > > > > If an 0.8 release is to occur the items called out are
> things
> >> >> which
> >> >> > > > > > impact licensing only (specifically the no longer allowed
> >> cat-x
> >> >> > json
> >> >> > > > > > library). I would be far more comfortable with 0.7.3
> release
> >> >> which
> >> >> > > > > > would be fixing whatever bugs have been addressed.  That
> >> avoids
> >> >> the
> >> >> > > > > > concern I noted above for this case though i'd still like
> us
> >> to
> >> >> > > > > > clarify that language/intent anyway.
> >> >> > > > > >
> >> >> > > > > > Thanks
> >> >> > > > > > Joe
> >> >> > > > > >
> >> >> > > > > > On Fri, Feb 24, 2017 at 3:21 PM, Brandon DeVries <
> [hidden email]
> >> >
> >> >> > > wrote:
> >> >> > > > > >
> >> >> > > > > > Team,
> >> >> > > > > >
> >> >> > > > > > The only unresolved tickets against the 0.8.0 release[1]
> are
> >> for
> >> >> > the
> >> >> > > > > > removal of code...  With that in mind, does anyone object
> to
> >> >> trying
> >> >> > > to
> >> >> > > > > >
> >> >> > > > > > push
> >> >> > > > > >
> >> >> > > > > > for this (possibly final) 0.x release?
> >> >> > > > > >
> >> >> > > > > > Brandon
> >> >> > > > > >
> >> >> > > > > > [1]
> >> >> > > > > > <a href="https://issues.apache.org/jira/issues/?jql=project%20%">https://issues.apache.org/jira/issues/?jql=project%20%
> >> >> > > > > >
> >> >> > > > > > 3D%20NIFI%20AND%20fixVersion%20%3D%200.8.0%20AND%
> >> >> > 20resolution%20%3D%
> >> >> > > > > > 20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%
> >> >> > > > > > 20DESC%2C%20created%20ASC
> >> >> > > > > >
> >> >> > > > > >
> >> >> > > > > >
> >> >> > > > >
> >> >> > > >
> >> >> > >
> >> >> >
> >> >>
> >>
>
Loading...