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 <[email protected]> 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" <[email protected]> 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 > > [email protected] > > *[email protected] <[email protected]>* > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > > > On Feb 24, 2017, at 2:07 PM, Tony Kurc <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 > > > > > > >
