Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 0424D200C34 for ; Mon, 27 Feb 2017 16:56:38 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 02AFB160B60; Mon, 27 Feb 2017 15:56:38 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id ED134160B56 for ; Mon, 27 Feb 2017 16:56:36 +0100 (CET) Received: (qmail 33920 invoked by uid 500); 27 Feb 2017 15:56:36 -0000 Mailing-List: contact dev-help@nifi.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@nifi.apache.org Delivered-To: mailing list dev@nifi.apache.org Received: (qmail 33906 invoked by uid 99); 27 Feb 2017 15:56:35 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 27 Feb 2017 15:56:35 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id 4DDFD18E84E for ; Mon, 27 Feb 2017 15:56:35 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.379 X-Spam-Level: *** X-Spam-Status: No, score=3.379 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_REPLY=1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id oY34L44StVGg for ; Mon, 27 Feb 2017 15:56:31 +0000 (UTC) Received: from mail-ua0-f169.google.com (mail-ua0-f169.google.com [209.85.217.169]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id A9ECD5F2C5 for ; Mon, 27 Feb 2017 15:56:30 +0000 (UTC) Received: by mail-ua0-f169.google.com with SMTP id e4so26655067uae.0 for ; Mon, 27 Feb 2017 07:56:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=k2Zw+Z0ApTN9IJRyjOsrE1xgCN1kKUAVrNVOpPR70vY=; b=Iix6e4bad8QQBmCfc2K950lNu8REQ1jn3Quq6ads0ZMemfNu6GTpEvS00gU3LRY7jA /PjuImPJvtX01qmV3BHPPiPMb02D8+aa82305miF+XzltAHGlfHYFbhaFNuCxGOCHd8V yMQSOBSHQJr6OaLz9qbTxdLImQi0SQSdDjgXg2H4gthvLrLzHhq3awXDduMs2o8ktMId TT+JrnphJZzOpsP1uyKLR6Mw3BFNVNaarKbOsJqohzheUGJtpXQM92jtTJRBOp4ZkU0o BGJ7zuguLtB+D1heabNcRThehuWRYHqquo+DFqB9Yhwv48Mqfw9F9/auqEwYe1HsrsIG Zhpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=k2Zw+Z0ApTN9IJRyjOsrE1xgCN1kKUAVrNVOpPR70vY=; b=HuHfmhFhg6btCPsLAh1SY/PGpUPrYIUp3uLFPnEQs+yFwFBSDPzh1ru1U4Qax7IwpP dV5HJYXFit+h+U1Y8Rd/WyDzUSEZShs9+jfia3g45JHzXyAv562oM86xCN2DKJsDaTEC ARQeFZtUmhgbllKj+2AH8obsxbIgUSSLTw82qoGipiQxM1aag37U57OlTaZH4VJtS20M mpzJxwcjZOM3S5fFx6kKU18dE6XzU+j8F6pshJqsAUprP6UQlZCHrURylpGBfrJ7cXC6 0WjQDorxByyY6mxX4j5ScXRPKNigLcEKex9QE3I3md6PxTkpfqN9222n8Y+juuCJVJjL X6Sw== X-Gm-Message-State: AMke39midnJwS85WjN8Oh0kOGzj9B5bLV7O+ScBkXT0ZxevPAlqxuGznREfxPK5lEWla6fGvlxdBF2wwdl8txw== X-Received: by 10.31.224.5 with SMTP id x5mr6321998vkg.80.1488210989418; Mon, 27 Feb 2017 07:56:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.48.67 with HTTP; Mon, 27 Feb 2017 07:55:49 -0800 (PST) In-Reply-To: References: <017BE142-6E90-488B-B7E0-9A565DF5D6A0@apache.org> From: Joe Skora Date: Mon, 27 Feb 2017 10:55:49 -0500 Message-ID: Subject: Re: Closing in on a NiFi 0.8.0 release? To: dev@nifi.apache.org Content-Type: multipart/alternative; boundary=94eb2c07cc80600f5d0549851f6e archived-at: Mon, 27 Feb 2017 15:56:38 -0000 --94eb2c07cc80600f5d0549851f6e Content-Type: text/plain; charset=UTF-8 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 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" 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 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 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" > 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 * > > > > > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > > > > > > > > > On Feb 24, 2017, at 2:07 PM, Tony Kurc 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 > > 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 > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > --94eb2c07cc80600f5d0549851f6e--