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 <b...@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.w...@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" <alopre...@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 > > > alopre...@apache.org > > > *alopresto.apa...@gmail.com <alopresto.apa...@gmail.com>* > > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > > > > > On Feb 24, 2017, at 2:07 PM, Tony Kurc <trk...@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.w...@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 <b...@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 > > > > > > > > > > > >
