nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Skora <jsk...@gmail.com>
Subject Re: Closing in on a NiFi 0.8.0 release?
Date Mon, 27 Feb 2017 15:55:49 GMT
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 <joe.witt@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" <jskora@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 <brd@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 <joe.witt@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 <alopresto.apache@gmail.com>*
> > > > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
> > > > >
> > > > > On Feb 24, 2017, at 2:07 PM, Tony Kurc <trkurc@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
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message