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 <joe.w...@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 <moser...@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 <joe.w...@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 <moser...@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 <jsk...@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 <joe.w...@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" <jsk...@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 <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 > >> >> > > > > > > >> >> > > > > > > >> >> > > > > > > >> >> > > > > > >> >> > > > > >> >> > > > >> >> > > >> >> > >> >
