From dev-return-60469-archive-asf-public=cust-asf.ponee.io@storm.apache.org Tue Aug 13 16:58:31 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [207.244.88.153]) by mx-eu-01.ponee.io (Postfix) with SMTP id 2C3E81804BB for ; Tue, 13 Aug 2019 18:58:31 +0200 (CEST) Received: (qmail 15310 invoked by uid 500); 13 Aug 2019 16:58:30 -0000 Mailing-List: contact dev-help@storm.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@storm.apache.org Delivered-To: mailing list dev@storm.apache.org Received: (qmail 15298 invoked by uid 99); 13 Aug 2019 16:58:30 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 13 Aug 2019 16:58:30 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 59E33C0A21 for ; Tue, 13 Aug 2019 16:58:29 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.801 X-Spam-Level: * X-Spam-Status: No, score=1.801 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-he-de.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id N0aeYmqTjK5S for ; Tue, 13 Aug 2019 16:58:24 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2607:f8b0:4864:20::32f; helo=mail-ot1-x32f.google.com; envelope-from=generalbas.srd@gmail.com; receiver= Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) by mx1-he-de.apache.org (ASF Mail Server at mx1-he-de.apache.org) with ESMTPS id A760B7D3FB for ; Tue, 13 Aug 2019 16:58:23 +0000 (UTC) Received: by mail-ot1-x32f.google.com with SMTP id c7so2599945otp.1 for ; Tue, 13 Aug 2019 09:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=uiPUxFxN1obpp+XRzBdLCVV/9p41fZbpi4oENtmtb8M=; b=qPr2jG76aWF8YaUeUoHZSOEAlVhmCEEV40Wvf691MD0CPOha//TTWvN7WBOlt5EBPa GB9lXwB2dDKPx5FYo8/Yyu6zmKZ9Zp4rbtSnxre3vATIVkrRJUlg4xfHSZGm92KaQGfb xTjTeCW6fu8LGASQtQ2niGDov/MVjEwD4N1ZRk/8K9TrqKCLndVmM8rCXgMZgQjfTR6Y 17P4gA0QsixQ5bdoqiZkg6iY3Gl5xH4jhRcAI7qTXhqGzKJE0qMso9trvcLcsEWefS9x 3sS4TgqV8L/bAgFfnG2BL+pFemroqQdWfvNB5N7jtZx752FGKO5BgwwtyVtNcHaVSs4D iS6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=uiPUxFxN1obpp+XRzBdLCVV/9p41fZbpi4oENtmtb8M=; b=dTk71ub6Fyy6E5uLfI79fEa4vDiWJeLTXk+1FCb6sB5mfQ+EbF3osx3+GO8i7klZpX fkS4zctHzUeXyIOePRnDXPljHS/wL0Tny/Hc+pyjVt82RUxupnGAWgjABaoGyZlmZTaE /ZAS5pxZn/ENK9qjWZIWzyl3CqBhEFXZjMYXFSRiL616Mt81XvlUqC0cr9FL0uQlrdnv WDIWink9+hb9au/lom4PTSDqjI0jJMVu0k7GImi8xvu+wCfO/z0aUa7+hM2Los4CjDtD Y4L0t8ztKxx1qqGH8lKdDXbL+7nY6X78JtYG9WrLZEGAFqEHoaKs1pCOvtvSE2UKeIKA 80yQ== X-Gm-Message-State: APjAAAWn8+S4gG4ZvqB7l/cxPamhvKmhdKwLBRaUQ7wI6H5Ltj5IPHRj caNP4wAl3H9SwKBMCEIpi0f+BRnDPZoCZq0PxmpiQZuO X-Google-Smtp-Source: APXvYqz+9XjdhLFHym09u3UYVL2SZBHw6eCL2ffR+tS6G9G0/8kwB/UcakjWc1/ypyrvBio5n+FcTB4hh+mwz3MP8x4= X-Received: by 2002:a9d:6a07:: with SMTP id g7mr8115681otn.282.1565715495942; Tue, 13 Aug 2019 09:58:15 -0700 (PDT) MIME-Version: 1.0 References: <2tzY1nYzSo3UgEI0_byRUZ42bpbNKRNYmFTWTvLbbM8mcIIjv1Wv4T4ZAS0acF0Isp6uUdXG19o9G1iMrez8BQ==@protonmail.internalid> <86643B96-B8B7-4354-98AD-AF0260C45A3F@gmail.com> <20190808221518.GC26391@dagit.name> <20190809135332.GA30551@dagit.name> <20190809195353.GA31067@dagit.name> <26C0598C-C737-4AC5-9194-0CE8F63B6126@gmail.com> <9C6A4375-BAF2-4801-93C1-49C80B6F6146@gmail.com> <95E0E4A1-BD29-433A-873D-EC44C237F1C7@gmail.com> <7249561A-F225-4C3E-A5CD-3F0F6D14F1F7@gmail.com> <69BB2732-D9C8-463F-9C35-7558D0F8CE8A@gmail.com> <4BA37104-3E51-4AE6-BD6C-B510988C689C@gmail.com> <12816261-1B8D-4196-9C3E-337ECFE6EB24@gmail.com> <2055B111-7BFF-47E8-A92E-F5C6781DDBB6@gmail.com> <1274C115-8A2B-40E3-8548-5944CA065D6F@gmail.com> In-Reply-To: <1274C115-8A2B-40E3-8548-5944CA065D6F@gmail.com> From: =?UTF-8?Q?Stig_Rohde_D=C3=B8ssing?= Date: Tue, 13 Aug 2019 18:58:04 +0200 Message-ID: Subject: Re: [DISCUSS] Next 2.x release To: dev@storm.apache.org Content-Type: multipart/alternative; boundary="000000000000f47ef50590028b18" --000000000000f47ef50590028b18 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Updated https://github.com/apache/storm/pull/3053 so we don't have org.apache.storm artifacts in the DEPENDENCY-LICENSES file. It's ready for review if someone wants to look at it. Den tir. 13. aug. 2019 kl. 18.21 skrev Ethan Li = : > Thank you, Taylor. Will delete them. > > > On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz wrote= : > > > > Those can be safely deleted. > > > > -Taylor > > > >> On Aug 13, 2019, at 12:15 PM, Ethan Li > wrote: > >> > >> Do we need/want to clean up the release candidate from > https://dist.apache.org/repos/dist/dev/storm < > https://dist.apache.org/repos/dist/dev/storm> ? > >> > >> > https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-t= he-vote-fails > < > https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-t= he-vote-fails> > says we do. But we have a lot of rc in > https://dist.apache.org/repos/dist/dev/storm/ < > https://dist.apache.org/repos/dist/dev/storm/> > >> > >> Just want to be absolutely sure about this. Thanks. > >> > >>> On Aug 13, 2019, at 10:56 AM, Ethan Li > wrote: > >>> > >>> That sounds better. It will be easier for release. Thank you for > looking into this. > >>> > >>>> On Aug 13, 2019, at 10:54 AM, Stig Rohde D=C3=B8ssing < > stigdoessing@gmail.com> wrote: > >>>> > >>>> Makes sense. I'll take a look at it. Ideally I'd want the license > files to > >>>> just not include org.apache.storm artifacts. I don't think we need t= o > tell > >>>> people that the project depends on itself. > >>>> > >>>> If we can exclude these artifacts from the lists, I don't think the > release > >>>> plugin needs to update these files. > >>>> > >>>> Den tir. 13. aug. 2019 kl. 17.36 skrev Ethan Li < > ethanopensource@gmail.com>: > >>>> > >>>>> Thanks Stig. > >>>>> > >>>>> In this case, we probably should abort release process and get this > merged > >>>>> into master first. Also we need to make sure it works with =E2=80= =9Cmvn > >>>>> release:prepare=E2=80=9D since =E2=80=9C mvn release:prepare=E2=80= =9D will automatically > push two > >>>>> commits. For example, > >>>>> > >>>>> (1) [maven-release-plugin] prepare release v2.1.0: this commit > changes > >>>>> the pom version to 2.1.0, push the commit, and then create a git ta= g > v2.1.0. > >>>>> > >>>>> (2) [maven-release-plugin] prepare for next development iteration: > this > >>>>> commit changes the pom version to 2.1.1-SNAPSHOT. > >>>>> > >>>>> > >>>>> We need DEPENDENCY-LICENSES to be updated on every step. > >>>>> > >>>>> > >>>>> > >>>>>> On Aug 13, 2019, at 10:24 AM, Stig Rohde D=C3=B8ssing < > stigdoessing@gmail.com> > >>>>> wrote: > >>>>>> > >>>>>> Oops, sorry that's not right. The license plugin setup was disable= d > in > >>>>>> https://github.com/apache/storm/pull/3031 due to a bug in the > license > >>>>>> plugin. It is added back in > https://github.com/apache/storm/pull/3053, > >>>>>> where we've upgraded the plugin. Until that PR goes in, we can't > easily > >>>>>> regenerate DEPENDENCY-LICENSES. > >>>>>> > >>>>>> Den tir. 13. aug. 2019 kl. 17.15 skrev Stig Rohde D=C3=B8ssing < > >>>>>> stigdoessing@gmail.com>: > >>>>>> > >>>>>>> There's a script that can help you do it in > >>>>>>> https://github.com/apache/storm/pull/3053. It checks the > >>>>>>> DEPENDENCY-LICENSES and LICENSE-binary contain the right > dependencies, > >>>>> and > >>>>>>> prints which licenses are redundant or should be added. > >>>>>>> > >>>>>>> For DEPENDENCY-LICENSES specifically you can run "mvn > >>>>>>> license:aggregate-add-third-party@generate-and-check-licenses > >>>>>>> -Dlicense.skipAggregateAddThirdParty=3Dfalse -B" in the project > root. It > >>>>>>> should update the file for you. > >>>>>>> > >>>>>>> Den tir. 13. aug. 2019 kl. 17.06 skrev Ethan Li < > >>>>> ethanopensource@gmail.com > >>>>>>>> : > >>>>>>> > >>>>>>>> Hi Stig, > >>>>>>>> > >>>>>>>> How do we update > >>>>>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? > < > >>>>>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?= > > Is > >>>>>>>> there a command I can use? Or I just replace strings manually? > >>>>>>>> > >>>>>>>> Thanks > >>>>>>>> Ethan > >>>>>>>> > >>>>>>>>> On Aug 12, 2019, at 3:54 PM, Ethan Li > > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> Yes my public keys in that file. Thanks! Ready to set up a vote= . > >>>>>>>>> > >>>>>>>>>> On Aug 12, 2019, at 3:52 PM, P. Taylor Goetz > > >>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> Yes. Is you public key in that file? If not you should add it. > >>>>>>>>>> > >>>>>>>>>> -Taylor > >>>>>>>>>> > >>>>>>>>>>> On Aug 12, 2019, at 4:15 PM, Ethan Li < > ethanopensource@gmail.com> > >>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> I have one more question before I can start a vote. > >>>>>>>>>>> > >>>>>>>>>>> In previous [VOTE] thread, Taylor always has this: > >>>>>>>>>>> > >>>>>>>>>>> The release artifacts are signed with the following key: > >>>>>>>>>>> > >>>>>>>> > >>>>> > https://git-wip-us.apache.org/repos/asf?p=3Dstorm.git;a=3Dblob_plain;f=3D= KEYS;hb=3D22b832708295fa2c15c4f3c70ac0d2bc6fded4bd > >>>>>>>> < > >>>>>>>> > >>>>> > https://git-wip-us.apache.org/repos/asf?p=3Dstorm.git;a=3Dblob_plain;f=3D= KEYS;hb=3D22b832708295fa2c15c4f3c70ac0d2bc6fded4bd > >>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Does anyone know where to find the updated KEYs file? Should = I > just > >>>>>>>> use https://www.apache.org/dist/storm/KEYS < > >>>>>>>> https://www.apache.org/dist/storm/KEYS> ? > >>>>>>>>>>> > >>>>>>>>>>> Thanks very much > >>>>>>>>>>> > >>>>>>>>>>>> On Aug 12, 2019, at 9:44 AM, Ethan Li < > ethanopensource@gmail.com> > >>>>>>>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks Stig and Taylor! It worked. I will continue the > process now > >>>>>>>> and update the documentation later. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> On Aug 12, 2019, at 9:40 AM, P. Taylor Goetz < > ptgoetz@gmail.com> > >>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> For the 2.x version lines, there are a bunch of profiles yo= u > need > >>>>>>>> to enable. This is what I use when preparing a release: > >>>>>>>>>>>>> > >>>>>>>>>>>>> -P dist,include-shaded-deps,rat,externals,examples > >>>>>>>>>>>>> > >>>>>>>>>>>>> -Taylor > >>>>>>>>>>>>> > >>>>>>>>>>>>>> On Aug 12, 2019, at 9:27 AM, Stig Rohde D=C3=B8ssing < > >>>>>>>> stigdoessing@gmail.com> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Try enabling the "dist" profile by adding "-P > >>>>>>>> dist,externals,examples" to > >>>>>>>>>>>>>> the command you're running. See > >>>>>>>>>>>>>> https://github.com/apache/storm/blob/master/pom.xml#L518. > Unless > >>>>>>>> you enable > >>>>>>>>>>>>>> that profile, the storm-dist modules aren't in the reactor= . > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Den man. 12. aug. 2019 kl. 15.15 skrev Ethan Li < > >>>>>>>> ethanopensource@gmail.com>: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Just in case if anyone happens to know the answer: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I created a branch > >>>>>>>> https://github.com/apache/storm/tree/2.1.x-branch < > >>>>>>>>>>>>>>> https://github.com/apache/storm/tree/2.1.x-branch> and ra= n > >>>>>>>> =E2=80=9Cmvn:prepare=E2=80=9D > >>>>>>>>>>>>>>> and =E2=80=9Cmvn:perform=E2=80=9D. It created two commits= and created a > v2.1.0 > >>>>>>>> git tag. But > >>>>>>>>>>>>>>> I realized that the pom version under storm-dist was not > updated > >>>>>>>> and it=E2=80=99s > >>>>>>>>>>>>>>> still 2.0.1-SNAPSHOT. I checked the commits in other tags > like > >>>>>>>>>>>>>>> https://github.com/apache/storm/commits/v2.0.0 < > >>>>>>>>>>>>>>> https://github.com/apache/storm/commits/v2.0.0> and it > looks > >>>>> like > >>>>>>>>>>>>>>> storm-dist got updated within the =E2=80=9Cmvn:prepare=E2= =80=9D step. How > do I > >>>>>>>> get > >>>>>>>>>>>>>>> storm-dist pom version updated with =E2=80=9Cmv:prepare= =E2=80=9D? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I am currently blocked on this. Any help will be > appreciated. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>> Ethan > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Aug 12, 2019, at 2:38 AM, Stig Rohde D=C3=B8ssing < > >>>>>>>> stigdoessing@gmail.com> > >>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Sounds good Ethan. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Derek, I also think being clear about how long we expect > to > >>>>>>>> support a > >>>>>>>>>>>>>>>> release line is a good idea. Maybe we should do a separa= te > >>>>>>>> discuss thread > >>>>>>>>>>>>>>>> on this, or if you already have a good idea for what the > policy > >>>>>>>> should > >>>>>>>>>>>>>>> look > >>>>>>>>>>>>>>>> like you could put it up as a PR for either the Download= s > page > >>>>>>>> or a new > >>>>>>>>>>>>>>>> page on the Storm site? > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Den s=C3=B8n. 11. aug. 2019 kl. 08.37 skrev Ethan Li < > >>>>>>>>>>>>>>> ethanopensource@gmail.com>: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> I am doing the release following > >>>>>>>>>>>>>>>>> https://github.com/apache/storm/blob/master/RELEASING.m= d > < > >>>>>>>>>>>>>>>>> https://github.com/apache/storm/blob/master/RELEASING.m= d> > . I > >>>>>>>> made some > >>>>>>>>>>>>>>>>> progress but I have some questions so I just sent an > email to > >>>>>>>> Taylor. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Please don=E2=80=99t merge anything to master or 2.1.x-= branch > for now. > >>>>>>>> Thanks > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Best, > >>>>>>>>>>>>>>>>> Ethan > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> On Aug 9, 2019, at 4:45 PM, Ethan Li < > >>>>>>>> ethanopensource@gmail.com> > >>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Currently we have two outstanding PRs that we wanted t= o > >>>>>>>> include in the > >>>>>>>>>>>>>>>>> new release: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3096 < > >>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3096> (Travis has > some > >>>>>>>> issues > >>>>>>>>>>>>>>>>> connecting to repository.apache.org < > >>>>>>>> http://repository.apache.org/> > >>>>>>>>>>>>>>>>> recently. Travis build fails consistently) > >>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878 < > >>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878> (Some > comments are > >>>>>>>> to be > >>>>>>>>>>>>>>>>> addressed but Author hasn=E2=80=99t responded yet.) > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> It=E2=80=99s not absolutely necessary to include them = in this > new > >>>>>>>> release so I > >>>>>>>>>>>>>>>>> think I should move forward with the release process. > These > >>>>> two > >>>>>>>> and > >>>>>>>>>>>>>>> other > >>>>>>>>>>>>>>>>> PRs can be included in the next release. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> For the release, I will create a new branch 2.1.x-bran= ch > >>>>> based > >>>>>>>> on > >>>>>>>>>>>>>>>>> current master branch, and release 2.1.0 from there. = I > will > >>>>>>>> then move > >>>>>>>>>>>>>>>>> master to 2.2.0-SNAPSHOT. Please let me know if there > is any > >>>>>>>>>>>>>>> objections. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>> Ethan > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On Aug 9, 2019, at 2:53 PM, Derek Dagit < > dagit@apache.org > >>>>>>>> >>>>>>>>>>>>>>>>> dagit@apache.org>> wrote: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> We might not able to say how long we want to support= a > >>>>>>>> specific > >>>>>>>>>>>>>>>>>>>> release line but I would love to see a clear release > policy > >>>>>>>> being > >>>>>>>>>>>>>>>>>>>> made. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> That makes sense. It seems better for us not to choos= e > a > >>>>>>>> specific > >>>>>>>>>>>>>>>>>>> calendar date or duration of time. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> - We do not want too many release lines supported > >>>>>>>> concurrently. > >>>>>>>>>>>>>>>>>>> - We want devs and users to know what to expect. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>> Derek > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On Fri, Aug 09, 2019 at 10:32:59AM -0500, Ethan Li > wrote: > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Derek, > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> I think it=E2=80=99s a good idea to be more clear on= the > versioning > >>>>>>>> and > >>>>>>>>>>>>>>>>> release process so users and developers know what to > expect. > >>>>> We > >>>>>>>> might > >>>>>>>>>>>>>>> not > >>>>>>>>>>>>>>>>> able to say how long we want to support a specific > release > >>>>> line > >>>>>>>> but I > >>>>>>>>>>>>>>> would > >>>>>>>>>>>>>>>>> love to see a clear release policy being made. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>> Ethan > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> On Aug 9, 2019, at 8:53 AM, Derek Dagit < > dagit@apache.org > >>>>>>>> >>>>>>>>>>>>>>>>> dagit@apache.org>> wrote: > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> On Fri, Aug 09, 2019 at 02:35:57PM +0200, Stig Rohd= e > >>>>>>>> D=C3=B8ssing wrote: > >>>>>>>>>>>>>>>>>>>>>> Where on the Traffic Server page do they list how > long > >>>>>>>> their > >>>>>>>>>>>>>>> release > >>>>>>>>>>>>>>>>>>>>>> trains survive? I only see dates of release, not > how long > >>>>>>>> e.g. 7.x > >>>>>>>>>>>>>>> is > >>>>>>>>>>>>>>>>>>>>>> supposed to receive support. Derek, > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> This is a better link: > >>>>>>>>>>>>>>>>> > >>>>>>>> https://cwiki.apache.org/confluence/display/TS/Release+Managemen= t > < > >>>>>>>>>>>>>>>>> > >>>>>>>> https://cwiki.apache.org/confluence/display/TS/Release+Managemen= t > > > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> This example, where "RM" means "Release Manager": > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> 1. We promise to make 1 major release / year, but > the RM > >>>>>>>> and > >>>>>>>>>>>>>>>>> community > >>>>>>>>>>>>>>>>>>>>>> can of course make more as necessary > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> 2. We only make releases off the LTS branches, > which are > >>>>>>>> cut once a > >>>>>>>>>>>>>>>>>>>>>> year off master > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> 3. Master is always open, for any type of change > >>>>> (including > >>>>>>>>>>>>>>>>>>>>>> incompatible changes). But don't break > compatibility just > >>>>>>>> for fun! > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> 4. Master is always stable, i.e. commits should be > >>>>>>>> properly tested > >>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>>>> reviewed before committed to master. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> 5. All releases are stable releases, following > strict > >>>>>>>> Semantic > >>>>>>>>>>>>>>>>>>>>>> Versioning. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> 6. Minor releases are made at the discretion at th= e > >>>>>>>> discretion of > >>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>> community and the RM. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> 7. Minor releases can include new (small / safe) > >>>>> features, > >>>>>>>> but must > >>>>>>>>>>>>>>>>> be > >>>>>>>>>>>>>>>>>>>>>> compatible within the LTS major version. > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> 8. The LTS cycle, 2 years + 6 months Sunset, does > not > >>>>>>>> reset when we > >>>>>>>>>>>>>>>>>>>>>> make a minor release. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Now, I am not proposing we do exactly this. The goa= l > would > >>>>>>>> be to set > >>>>>>>>>>>>>>>>>>>>> expectations among developers and the community, an= d > here > >>>>>>>> is one > >>>>>>>>>>>>>>>>>>>>> concrete example of how it could be done. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> If we're going to promise that a release line > survives > >>>>> for > >>>>>>>> a given > >>>>>>>>>>>>>>>>>>>>>> amount of time, I think we should do it at the maj= or > >>>>>>>> version level > >>>>>>>>>>>>>>>>>>>>>> only > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Yeah, that sounds reasonable to me. If we choose to > commit > >>>>>>>> to > >>>>>>>>>>>>>>>>> something > >>>>>>>>>>>>>>>>>>>>> like the above, we should base the decision in part > on > >>>>> what > >>>>>>>> kind of > >>>>>>>>>>>>>>>>>>>>> resources we have so that we do not over-commit. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> Den fre. 9. aug. 2019 kl. 00.15 skrev Derek Dagit = < > >>>>>>>>>>>>>>> dagit@apache.org > >>>>>>>>>>>>>>>>> >: > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> What do we think about defining Long-Term Support > >>>>>>>> branches with a > >>>>>>>>>>>>>>>>> fixed > >>>>>>>>>>>>>>>>>>>>>>> period of support? > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> For example, we could say 2.0.x is an LTS release > line > >>>>>>>> with > >>>>>>>>>>>>>>> support > >>>>>>>>>>>>>>>>>>>>>>> ending no earlier than a certain calendar date. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> The date could be extended, and it might > ultimately be > >>>>>>>> governed by > >>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>> timing of the subsequent release (e.g., 2.1.x or > 3.0.x). > >>>>>>>> Keeping > >>>>>>>>>>>>>>>>> things > >>>>>>>>>>>>>>>>>>>>>>> clear would imply semantic versioning as mentione= d > >>>>> earlier > >>>>>>>>>>>>>>>>>>>>>>> (https://semver.org/ ). > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Apache Traffic Server does something like this, t= o > name > >>>>>>>> one > >>>>>>>>>>>>>>> project: > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> https://trafficserver.apache.org/downloads < > >>>>>>>>>>>>>>>>> https://trafficserver.apache.org/downloads> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> Having a regular cadence of releases might also > help > >>>>> make > >>>>>>>> the > >>>>>>>>>>>>>>>>> process > >>>>>>>>>>>>>>>>>>>>>>> easier and help set expectations for users and > devs. > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>>>>>>>>> Derek > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> On Thu, Aug 08, 2019 at 02:50:07PM -0500, Ethan L= i > >>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Currently we don=E2=80=99t have a 2.0.x-branch a= nd master > is > >>>>>>>> actually > >>>>>>>>>>>>>>>>>>>>>>> =E2=80=9C2.0.1-SNAPSHOT=E2=80=9D. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> So if we do a 2.1.0 release, we will create a > >>>>>>>> 2.1.x-branch > >>>>>>>>>>>>>>> based > >>>>>>>>>>>>>>>>> on > >>>>>>>>>>>>>>>>>>>>>>> current master, release from there. And we change > master > >>>>>>>> to > >>>>>>>>>>>>>>>>>>>>>>> =E2=80=9C2.2.0-SNAPSHOT=E2=80=9D. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> But we will have one problem: we will lose 2.0.x > >>>>> release > >>>>>>>> line. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> There are two things I can do: > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> 1) create a 2.0.x-branch based on v2.0.0 tag. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> 2) ignore it. If there is an issue with 2.0.x > release, > >>>>>>>> ask users > >>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>>>>> upgrade to 2.1.0. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> I prefer 1) but not sure if it=E2=80=99s the rig= ht way to > make > >>>>>>>> things > >>>>>>>>>>>>>>>>> right. Or > >>>>>>>>>>>>>>>>>>>>>>> please let me know if I misunderstood something > and it=E2=80=99s > >>>>>>>> not an > >>>>>>>>>>>>>>>>> issue. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Btw, I am seeing the same issue with 1.x-branch. > We > >>>>>>>> shouldn=E2=80=99t > >>>>>>>>>>>>>>> have > >>>>>>>>>>>>>>>>>>>>>>> 1.x-branch. Instead, we should have 1.2.x-branch. > But > >>>>>>>> this is not > >>>>>>>>>>>>>>> a > >>>>>>>>>>>>>>>>> problem > >>>>>>>>>>>>>>>>>>>>>>> since we will not release 1.3.x. > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>>>>> Ethan > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:43 AM, Ethan Li < > >>>>>>>>>>>>>>> ethanopensource@gmail.com> > >>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks. > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde D=C3= =B8ssing > < > >>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great. Remember to add your key to > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>> https://dist.apache.org/repos/dist/release/storm/KEYS, > >>>>>>>> you > >>>>>>>>>>>>>>>>> should be > >>>>>>>>>>>>>>>>>>>>>>> able > >>>>>>>>>>>>>>>>>>>>>>>>>> to update it with an SVN client. See also > >>>>>>>>>>>>>>>>>>>>>>>>>> https://www.apache.org/dev/openpgp.html#update= . > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> Den ons. 7. aug. 2019 kl. 15.05 skrev Ethan Li= < > >>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>: > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call < > >>>>>>>> bcall@apache.org > >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> bcall@apache.org>> (Thanks to him). > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> My pgp key: > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>> > >>>>> > http://pgp.surfnet.nl/pks/lookup?op=3Dvindex&fingerprint=3Don&search=3D0x= A4A672F11B5050C8 > >>>>>>>>>>>>>>>>>>>>>>>>>>> < > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>> > >>>>> > http://pgp.surfnet.nl/pks/lookup?op=3Dvindex&fingerprint=3Don&search=3D0x= A4A672F11B5050C8 > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> My understanding is that I am good to do > release > >>>>> with > >>>>>>>> this key > >>>>>>>>>>>>>>>>> now. > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Here is a list of PRs that we might want to > include > >>>>>>>> in the new > >>>>>>>>>>>>>>>>>>>>>>> release: > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3098 < > >>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3098> > >>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3096 < > >>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3096> > >>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878 < > >>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878> > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Please review if you get a chance. Thanks > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> Ethan > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 1, 2019, at 4:19 AM, Stig Rohde > D=C3=B8ssing < > >>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com> > >>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense. > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan > Li < > >>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>: > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> It=E2=80=99s a good point. I will start a d= iscussion > >>>>> thread > >>>>>>>> for it. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> For the new release, I went through the lis= t: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>> > >>>>> > https://issues.apache.org/jira/issues/?jql=3Dproject%20%3D%20STORM%20AND%= 20fixVersion%20%3D%202.0.1 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> < > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>> > >>>>> > https://issues.apache.org/jira/issues/?jql=3Dproject%20=3D%20STORM%20AND%= 20fixVersion%20=3D%202.0.1 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> We introduced some new functionalities, > including > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > https://issues.apache.org/jira/browse/STORM-2720 > >>>>> < > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > https://issues.apache.org/jira/browse/STORM-2720> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > https://issues.apache.org/jira/browse/STORM-3412 > >>>>> < > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > https://issues.apache.org/jira/browse/STORM-3412> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > https://issues.apache.org/jira/browse/STORM-3411 > >>>>> < > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > https://issues.apache.org/jira/browse/STORM-3411> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > https://issues.apache.org/jira/browse/STORM-3442 > >>>>> < > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > https://issues.apache.org/jira/browse/STORM-3442> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > https://issues.apache.org/jira/browse/STORM-3396 > >>>>> < > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > https://issues.apache.org/jira/browse/STORM-3396> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > https://issues.apache.org/jira/browse/STORM-3392 > >>>>> < > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > https://issues.apache.org/jira/browse/STORM-3392> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > https://issues.apache.org/jira/browse/STORM-3395 > >>>>> < > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > https://issues.apache.org/jira/browse/STORM-3395> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> So I think we should release 2.1.0 rather > than > >>>>>>>> 2.0.1. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are a few pull requests we may want t= o > >>>>> review > >>>>>>>> before > >>>>>>>>>>>>>>>>> the next > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> release: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3094 < > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3094> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2990 < > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2990> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878 < > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ethan > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 29, 2019, at 10:11 AM, Hugo Louro < > >>>>>>>>>>>>>>> hmclouro@gmail.com > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think it would facilitate more frequent > >>>>> releases > >>>>>>>> to > >>>>>>>>>>>>>>>>> summarize > >>>>>>>>>>>>>>>>>>>>>>> in a > >>>>>>>>>>>>>>>>>>>>>>>>>>> page > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the testing that all > contributors/committers do > >>>>> in > >>>>>>>>>>>>>>>>> anticipation > >>>>>>>>>>>>>>>>>>>>>>> of the > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release, plus any "new" testing that may > become > >>>>>>>> relevant > >>>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>> newer > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> releases. Doing so would make it easy to > create a > >>>>>>>> check > >>>>>>>>>>>>>>> form > >>>>>>>>>>>>>>>>> or or > >>>>>>>>>>>>>>>>>>>>>>>>>>> email > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> template that what we feel should be done = to > >>>>>>>> guarantee a > >>>>>>>>>>>>>>>>> stable > >>>>>>>>>>>>>>>>>>>>>>>>>>> release. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hugo > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Jul 29, 2019 at 7:15 AM Ethan Li < > >>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde > >>>>> D=C3=B8ssing < > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think ideally we've been trying for > semver, > >>>>>>>> but it's > >>>>>>>>>>>>>>> been > >>>>>>>>>>>>>>>>>>>>>>> pretty > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> loose, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> e.g. there were breaking changes in one > of the > >>>>>>>> 1.2.x > >>>>>>>>>>>>>>>>> releases > >>>>>>>>>>>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> storm-kafka-client. I don't know what > rules > >>>>> we've > >>>>>>>>>>>>>>> actually > >>>>>>>>>>>>>>>>> been > >>>>>>>>>>>>>>>>>>>>>>>>>>> using, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> if > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> any. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Semver for binary compatibility would > probably > >>>>>>>> be a good > >>>>>>>>>>>>>>>>> rule of > >>>>>>>>>>>>>>>>>>>>>>>>>>> thumb. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 20.01 skrev > Ethan > >>>>> Li < > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Stig, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Do you know what=E2=80=99s the versioni= ng > standard we > >>>>>>>> have been > >>>>>>>>>>>>>>>>>>>>>>> following > >>>>>>>>>>>>>>>>>>>>>>>>>>> (to > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> determine a 2.0.1 release or 2.1.0 > release) ? > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 12:26 PM, Stig Roh= de > >>>>>>>> D=C3=B8ssing < > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev > Ethan > >>>>>>>> Li < > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It=E2=80=99s good idea to do more fre= quent > release. > >>>>> I > >>>>>>>> can run > >>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>> next > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I will take a look at both PRs. Other > than > >>>>>>>> that, I > >>>>>>>>>>>>>>>>> think we > >>>>>>>>>>>>>>>>>>>>>>> should > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> also > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> get > >>>>> https://github.com/apache/storm/pull/3093 > >>>>>>>> < > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > https://github.com/apache/storm/pull/3093> > >>>>>>>> in the > >>>>>>>>>>>>>>> new > >>>>>>>>>>>>>>>>>>>>>>> release. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 11:58 AM, Stig > Rohde > >>>>>>>> D=C3=B8ssing < > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think we've talked about more > frequent > >>>>>>>> releases > >>>>>>>>>>>>>>>>> before. > >>>>>>>>>>>>>>>>>>>>>>>>>>> Releasing > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> new > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> versions every few months means peop= le > >>>>> don't > >>>>>>>> have to > >>>>>>>>>>>>>>>>> wait > >>>>>>>>>>>>>>>>>>>>>>> long > >>>>>>>>>>>>>>>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fixes > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> get out, and smaller releases are > probably > >>>>>>>> also > >>>>>>>>>>>>>>> easier > >>>>>>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>>>>>>>> users > >>>>>>>>>>>>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> get > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> grips with (the fix list for 2.0.0 i= s > >>>>>>>> enormous). > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> With that in mind, I think we should > start > >>>>>>>> looking at > >>>>>>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>>>>>>>> next > >>>>>>>>>>>>>>>>>>>>>>>>>>> 2.x > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (2.0.1 or 2.1.0?), since it's been a > couple > >>>>>>>> of months > >>>>>>>>>>>>>>>>> since > >>>>>>>>>>>>>>>>>>>>>>> 2.0.0 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> released. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The fix list would be > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>> > >>>>> > https://issues.apache.org/jira/issues/?jql=3Dproject%20%3D%20STORM%20AND%= 20fixVersion%20%3D%202.0.1 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> . > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Govind and Ethan have offered to run > the > >>>>> next > >>>>>>>>>>>>>>> release, > >>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>>>>> help > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> validate > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> our release process guidelines. Woul= d > one > >>>>> of > >>>>>>>> you have > >>>>>>>>>>>>>>>>> time > >>>>>>>>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>>>>>>>>> work > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on a > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release in the near future? > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It would be good to take a look at > >>>>> currently > >>>>>>>> open PRs > >>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>>>>>> decide > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> we > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> feel need to get merged before the > next > >>>>>>>> release. > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would like to see at least > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2990 > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> merged > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > https://github.com/apache/storm/pull/2878 > >>>>>>>> seems like > >>>>>>>>>>>>>>>>> it's > >>>>>>>>>>>>>>>>>>>>>>> close > >>>>>>>>>>>>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mergeable too? > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>> > >>>>> > >>> > >> > > > > > > > --000000000000f47ef50590028b18--