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 <[email protected]> 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 <[email protected]> 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 <[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 >> > > >> > > >> > > >> > >>
