You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@nifi.apache.org by Michael Moser <mo...@gmail.com> on 2017/04/12 22:17:30 UTC
Re: Closing in on a NiFi 0.8.0 release?
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 <js...@gmail.com> 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 <jo...@gmail.com> 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" <js...@gmail.com> 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 <br...@jhu.edu> 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]
> > > > 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 <jo...@gmail.com> 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" <al...@apache.org>
> > 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
> > > > > > alopresto@apache.org
> > > > > > *alopresto.apache@gmail.com <al...@gmail.com>*
> > > > > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D
> EF69
> > > > > >
> > > > > > On Feb 24, 2017, at 2:07 PM, Tony Kurc <tr...@gmail.com> 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 <jo...@gmail.com>
> > > 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 <br...@jhu.edu>
> > > 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
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: Closing in on a NiFi 0.8.0 release?
Posted by Michael Moser <mo...@gmail.com>.
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 <jo...@gmail.com> 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 <mo...@gmail.com> 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 <jo...@gmail.com> 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 <mo...@gmail.com>
> 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 <js...@gmail.com> 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 <jo...@gmail.com>
> 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" <js...@gmail.com> 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 <br...@jhu.edu>
> >> 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]
> >> >> > > > 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 <jo...@gmail.com>
> >> 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" <
> alopresto@apache.org>
> >> >> > 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
> >> >> > > > > > alopresto@apache.org
> >> >> > > > > > *alopresto.apache@gmail.com <al...@gmail.com>*
> >> >> > > > > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B
> 2F7D
> >> >> EF69
> >> >> > > > > >
> >> >> > > > > > On Feb 24, 2017, at 2:07 PM, Tony Kurc <tr...@gmail.com>
> >> 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 <
> joe.witt@gmail.com
> >> >
> >> >> > > 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 <
> brd@jhu.edu
> >> >
> >> >> > > 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
> >> >> > > > > >
> >> >> > > > > >
> >> >> > > > > >
> >> >> > > > >
> >> >> > > >
> >> >> > >
> >> >> >
> >> >>
> >>
>
Re: Closing in on a NiFi 0.8.0 release?
Posted by Joe Witt <jo...@gmail.com>.
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 <mo...@gmail.com> 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 <jo...@gmail.com> 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 <mo...@gmail.com> 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 <js...@gmail.com> 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 <jo...@gmail.com> 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" <js...@gmail.com> 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 <br...@jhu.edu>
>> 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]
>> >> > > > 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 <jo...@gmail.com>
>> 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" <al...@apache.org>
>> >> > 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
>> >> > > > > > alopresto@apache.org
>> >> > > > > > *alopresto.apache@gmail.com <al...@gmail.com>*
>> >> > > > > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D
>> >> EF69
>> >> > > > > >
>> >> > > > > > On Feb 24, 2017, at 2:07 PM, Tony Kurc <tr...@gmail.com>
>> 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 <joe.witt@gmail.com
>> >
>> >> > > 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 <brd@jhu.edu
>> >
>> >> > > 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
>> >> > > > > >
>> >> > > > > >
>> >> > > > > >
>> >> > > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>>
Re: Closing in on a NiFi 0.8.0 release?
Posted by Michael Moser <mo...@gmail.com>.
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 <jo...@gmail.com> 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 <mo...@gmail.com> 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 <js...@gmail.com> 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 <jo...@gmail.com> 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" <js...@gmail.com> 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 <br...@jhu.edu>
> 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]
> >> > > > 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 <jo...@gmail.com>
> 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" <al...@apache.org>
> >> > 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
> >> > > > > > alopresto@apache.org
> >> > > > > > *alopresto.apache@gmail.com <al...@gmail.com>*
> >> > > > > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D
> >> EF69
> >> > > > > >
> >> > > > > > On Feb 24, 2017, at 2:07 PM, Tony Kurc <tr...@gmail.com>
> 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 <joe.witt@gmail.com
> >
> >> > > 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 <brd@jhu.edu
> >
> >> > > 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
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>
Re: Closing in on a NiFi 0.8.0 release?
Posted by Joe Witt <jo...@gmail.com>.
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 <mo...@gmail.com> 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 <js...@gmail.com> 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 <jo...@gmail.com> 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" <js...@gmail.com> 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 <br...@jhu.edu> 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]
>> > > > 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 <jo...@gmail.com> 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" <al...@apache.org>
>> > 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
>> > > > > > alopresto@apache.org
>> > > > > > *alopresto.apache@gmail.com <al...@gmail.com>*
>> > > > > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D
>> EF69
>> > > > > >
>> > > > > > On Feb 24, 2017, at 2:07 PM, Tony Kurc <tr...@gmail.com> 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 <jo...@gmail.com>
>> > > 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 <br...@jhu.edu>
>> > > 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
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > >
>> > > >
>> > >
>> >
>>