From dev-return-60531-archive-asf-public=cust-asf.ponee.io@storm.apache.org Mon Aug 19 16:15:36 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 5DB00180665 for ; Mon, 19 Aug 2019 18:15:35 +0200 (CEST) Received: (qmail 98800 invoked by uid 500); 19 Aug 2019 16:15:34 -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 98788 invoked by uid 99); 19 Aug 2019 16:15:34 -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, 19 Aug 2019 16:15:34 +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 23829180C91 for ; Mon, 19 Aug 2019 16:15:33 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.151 X-Spam-Level: ** X-Spam-Status: No, score=2.151 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, HTML_TAG_BALANCE_BODY=0.1, KAM_LOTSOFHASH=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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-he-de.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id w8-a9sqY-N1K for ; Mon, 19 Aug 2019 16:15:26 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2607:f8b0:4864:20::d34; helo=mail-io1-xd34.google.com; envelope-from=ethanopensource@gmail.com; receiver= Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) by mx1-he-de.apache.org (ASF Mail Server at mx1-he-de.apache.org) with ESMTPS id B8F367DC05 for ; Mon, 19 Aug 2019 16:15:25 +0000 (UTC) Received: by mail-io1-xd34.google.com with SMTP id t3so5466458ioj.12 for ; Mon, 19 Aug 2019 09:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=R7abhMAxjLsIPh8DFT3GRcXQOYCB8HO0PKoBGPEn+Xs=; b=hugRjBa04hjI3kGeIFODD8vRbJv8Dbv3u58gvQ7p3pB81sbxZcwTS53eLRHP+/2mi6 Rj31lQfjgwPM3DazMBDZrJVRIDY9xiItqt/VG/9CJQrSEyK9GHO8DCkBY5Y7FJ/Etejr OPBq6Fizl/UisFWCVxDCg2WtBjmKRu8LEkTRcQA7YK/sOFghjQBmosq2JfSoT7G9dqdX i8d/bE5WSDNGMedjFd4N6WMo8ydYJEFvznV38xNTEuc+8y3+0eipUubYsi1sVhDItCt6 iTmeMBNuFVsGz7QaZhjzp+PmQPt3nAXnjPJFIff8tKG1Qtk4EwUrkdkQ8lkjbNsukPgy OocA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=R7abhMAxjLsIPh8DFT3GRcXQOYCB8HO0PKoBGPEn+Xs=; b=F77uQ36Rz6o6Lm+li9y4vpHYxRHnWNe1H3DTW3fPSi1JogYA/E621my2xDH+W5Mizn 4C4fu32QcuBqU0kTDdF9HOfS4SU/HOufhl69hZAnsJsGzW7rXqsva3/k4miyQibygcoo xSe5FziG1tHObQVvUtjJhMbSyHVaM0reljnyzDjQ08sG9ezGtYSThNzUoEfyicO6UkYV 0cRKCeb0H2CSk6VcX7tEX5Xz0A09ooHxl+dmtaAlZWcc2eYWIqM3Mh6XpVuCftNW457f frHfJbjxi0CaWDHU6qv7brXyW+rmBhGckE2xHhLdHjIgj5/0mwOqdTWFDDaI2YBPPfxi a4yQ== X-Gm-Message-State: APjAAAVmZ02hXMMUOCkoucz+M+4Fbr9T+Gvy0u+g1jleoV9swV8DfYIf Ikbo9HxgK8HOqX1DkQbo8EcEYazQJ78= X-Google-Smtp-Source: APXvYqxJdj08uirR3152zxlYpvkJ2mMjm6E7VQk36Fc6n7KvnJNJiljE6zaQJTLHF9YwYiETfQUGFw== X-Received: by 2002:a5e:9741:: with SMTP id h1mr4378413ioq.24.1566231318358; Mon, 19 Aug 2019 09:15:18 -0700 (PDT) Received: from ?IPv6:2001:4998:efe9:100:714e:9abb:cac1:69e3? ([2001:4998:efe9:100:714e:9abb:cac1:69e3]) by smtp.gmail.com with ESMTPSA id 8sm14015522ion.26.2019.08.19.09.15.16 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Aug 2019 09:15:17 -0700 (PDT) From: Ethan Li Content-Type: multipart/alternative; boundary="Apple-Mail=_BF1A71AC-F893-45F5-BC15-8F8D100C3719" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: [DISCUSS] Next 2.x release Date: Mon, 19 Aug 2019 11:15:16 -0500 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> <0C7C1ED5-0044-408B-945E-EDA9688242A8@gmail.com> To: dev@storm.apache.org In-Reply-To: Message-Id: <89FDD8CE-2211-4997-84D3-2D08992A11E9@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) --Apple-Mail=_BF1A71AC-F893-45F5-BC15-8F8D100C3719 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Many issues came up while I was preparing for 2.1.0 release. Freezing = merge until the release is done is not practical. So I am proposing: 1. Once we decide to make a release, we create a new branch based on = master and start release process.=20 2. During the new process, master is still open for backwards = compatibility commits, including new features, bu=10g fixes, etc.=20 3. Only bug fixes will be merged to the new branch and we need to = restart the release process to include the bug fixes. 4. To avoid too much confusion on pom versions when we merge new commits = during the release process, we should use less concrete version. For = example, in 2.1.x-branch, the pom version should be 2.1-SNAPSHOT, = instead of 2.1.0-SNAPSHOT.=20 For example, Let=E2=80=99s say we have a new branch 2.1.x-branch, the pom version is = 2.1.0-SNAPSHOT. We start the release process and after running the mvn = release:prepare -Pxxx command, the pom version changes to = 2.1.1-SNAPSHOT, and before that a git tag v2.1.0 is created. Now if = there is a bug fix we have to merge in, so we merge in and it=E2=80=99s = actually merged in to 2.1.1-SNAPSHOT at this point if we don=E2=80=99t = manually revert the pom version, which can be confusing. We can avoid = this problem by just using 2.1-SNAPSHOT as the pom version. So it = doesn=E2=80=99t have to change.=20 Please let me know if there is any potential risk for doing this. Thanks Ethan > On Aug 19, 2019, at 10:25 AM, Ethan Li = wrote: >=20 > The pull request for the fix is = https://github.com/apache/storm/pull/3106 = >=20 >> On Aug 19, 2019, at 10:15 AM, Ethan Li > wrote: >>=20 >> So I was preparing for a new release candidate i.e. rc3. I can build = it from source without any problem. Then I set up a standalone cluster = and submitted a WordCountTopology. The workers kept restarting because = of=20 >>=20 >>=20 >> 2019-08-19 15:09:49.635 o.a.s.t.ShellBolt Thread-30 [ERROR] Halting = process: ShellBolt died. Command: [python, splitsentence.py], = ProcessInfo pid:3756, name:split exitCode:-1, errorString: >> java.lang.IllegalArgumentException: command sync is not supported >> at = org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)= [storm-client-2.1.0.jar:2.1.0] >> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181] >> 2019-08-19 15:09:49.635 o.a.s.e.e.ReportError Thread-30 [ERROR] Error >> java.lang.IllegalArgumentException: command sync is not supported >> at = org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)= [storm-client-2.1.0.jar:2.1.0] >> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181] >> 2019-08-19 15:09:49.636 o.a.s.t.ShellBolt Thread-28 [ERROR] Halting = process: ShellBolt died. Command: [python, splitsentence.py], = ProcessInfo pid:3755, name:split exitCode:-1, errorString: >> java.lang.IllegalArgumentException: command sync is not supported >> at = org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)= [storm-client-2.1.0.jar:2.1.0] >> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181] >> 2019-08-19 15:09:49.637 o.a.s.e.e.ReportError Thread-28 [ERROR] Error >> java.lang.IllegalArgumentException: command sync is not supported >> at = org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)= [storm-client-2.1.0.jar:2.1.0] >> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181] >>=20 >>=20 >>=20 >> = https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apach= e/storm/task/ShellBolt.java#L365-L367 = I believe we shouldn=E2=80=99t = throw exceptions here.=20 >>=20 >> Will make a pull request to fix it.=20 >>=20 >>=20 >>=20 >>> On Aug 14, 2019, at 11:11 PM, Ethan Li > wrote: >>>=20 >>> Hi Taylor, >>>=20 >>> Mostly I was able to follow the doc = https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote= = , except: >>>=20 >>> For Step 1, I used the following command as suggested. >>> mvn release:prepare -P dist,rat,externals,examples >>> mvn release:perform -P dist,rat,externals,examples >>>=20 >>>=20 >>> For Step3, I had to run "git checkout tags/v2.1.0 -b v2.1.0=E2=80=9D = so that I can run =E2=80=9Cmvn package=E2=80=9D for storm-dist/binary = and storm-dist/source based on v2.1.0. Otherwise if I run =E2=80=9Cmvn = package=E2=80=9D on 2.1.x-branch, it will fail because the pom version = is =E2=80=9C2.1.x-SNAPSHOT=E2=80=9D.=20 >>>=20 >>> Then I find packages in storm-dist/binary/final-package/target and = storm-dist/source/target, sign them, generate checksum and copy them to = svn. >>>=20 >>> I think there are something I should do. But please let me know if I = was doing something wrong. I will also update the doc after the = release is complete. Thank you very much! >>>=20 >>> Ethan >>>=20 >>>=20 >>>> On Aug 14, 2019, at 12:24 PM, Ethan Li > wrote: >>>>=20 >>>> I am continuing for another release candidate since the pr is = merged.=20 >>>>=20 >>>>> On Aug 13, 2019, at 11:58 AM, Stig Rohde D=C3=B8ssing = > wrote: >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Den tir. 13. aug. 2019 kl. 18.21 skrev Ethan Li = >: >>>>>=20 >>>>>> Thank you, Taylor. Will delete them. >>>>>>=20 >>>>>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz > wrote: >>>>>>>=20 >>>>>>> Those can be safely deleted. >>>>>>>=20 >>>>>>> -Taylor >>>>>>>=20 >>>>>>>> On Aug 13, 2019, at 12:15 PM, Ethan Li = > >>>>>> wrote: >>>>>>>>=20 >>>>>>>> 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 = > ? >>>>>>>>=20 >>>>>>>>=20 >>>>>> = https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-th= e-vote-fails = >>>>>> < >>>>>> = https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-th= e-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/ = > >>>>>>>>=20 >>>>>>>> Just want to be absolutely sure about this. Thanks. >>>>>>>>=20 >>>>>>>>> On Aug 13, 2019, at 10:56 AM, Ethan Li = > >>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> That sounds better. It will be easier for release. Thank you = for >>>>>> looking into this. >>>>>>>>>=20 >>>>>>>>>> On Aug 13, 2019, at 10:54 AM, Stig Rohde D=C3=B8ssing < >>>>>> stigdoessing@gmail.com > wrote: >>>>>>>>>>=20 >>>>>>>>>> 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 to >>>>>> tell >>>>>>>>>> people that the project depends on itself. >>>>>>>>>>=20 >>>>>>>>>> If we can exclude these artifacts from the lists, I don't = think the >>>>>> release >>>>>>>>>> plugin needs to update these files. >>>>>>>>>>=20 >>>>>>>>>> Den tir. 13. aug. 2019 kl. 17.36 skrev Ethan Li < >>>>>> ethanopensource@gmail.com >: >>>>>>>>>>=20 >>>>>>>>>>> Thanks Stig. >>>>>>>>>>>=20 >>>>>>>>>>> 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, >>>>>>>>>>>=20 >>>>>>>>>>> (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 tag >>>>>> v2.1.0. >>>>>>>>>>>=20 >>>>>>>>>>> (2) [maven-release-plugin] prepare for next development = iteration: >>>>>> this >>>>>>>>>>> commit changes the pom version to 2.1.1-SNAPSHOT. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> We need DEPENDENCY-LICENSES to be updated on every step. >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>> On Aug 13, 2019, at 10:24 AM, Stig Rohde D=C3=B8ssing < >>>>>> stigdoessing@gmail.com > >>>>>>>>>>> wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> Oops, sorry that's not right. The license plugin setup was = disabled >>>>>> 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. >>>>>>>>>>>>=20 >>>>>>>>>>>> Den tir. 13. aug. 2019 kl. 17.15 skrev Stig Rohde D=C3=B8ssin= g < >>>>>>>>>>>> stigdoessing@gmail.com >: >>>>>>>>>>>>=20 >>>>>>>>>>>>> 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. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> 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. >>>>>>>>>>>>>=20 >>>>>>>>>>>>> Den tir. 13. aug. 2019 kl. 17.06 skrev Ethan Li < >>>>>>>>>>> ethanopensource@gmail.com >>>>>>>>>>>>>> : >>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Hi Stig, >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> 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? >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> On Aug 12, 2019, at 3:54 PM, Ethan Li = >>>>>>>=20 >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>> Yes my public keys in that file. Thanks! Ready to set up = a vote. >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> On Aug 12, 2019, at 3:52 PM, P. Taylor Goetz = >>>>>>>=20 >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> Yes. Is you public key in that file? If not you should = add it. >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>> -Taylor >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> On Aug 12, 2019, at 4:15 PM, Ethan Li < >>>>>> ethanopensource@gmail.com > >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> I have one more question before I can start a vote. >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> In previous [VOTE] thread, Taylor always has this: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> The release artifacts are signed with the following = key: >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>> = https://git-wip-us.apache.org/repos/asf?p=3Dstorm.git;a=3Dblob_plain;f=3DK= EYS;hb=3D22b832708295fa2c15c4f3c70ac0d2bc6fded4bd = >>>>>>>>>>>>>> < >>>>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>> = https://git-wip-us.apache.org/repos/asf?p=3Dstorm.git;a=3Dblob_plain;f=3DK= EYS;hb=3D22b832708295fa2c15c4f3c70ac0d2bc6fded4bd = >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> 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> ? >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>> Thanks very much >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> On Aug 12, 2019, at 9:44 AM, Ethan Li < >>>>>> ethanopensource@gmail.com> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>> Thanks Stig and Taylor! It worked. I will continue = the >>>>>> process now >>>>>>>>>>>>>> and update the documentation later. >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> On Aug 12, 2019, at 9:40 AM, P. Taylor Goetz < >>>>>> ptgoetz@gmail.com> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> For the 2.x version lines, there are a bunch of = profiles you >>>>>> need >>>>>>>>>>>>>> to enable. This is what I use when preparing a release: >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> -P dist,include-shaded-deps,rat,externals,examples >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>> -Taylor >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> On Aug 12, 2019, at 9:27 AM, Stig Rohde D=C3=B8ssing = < >>>>>>>>>>>>>> stigdoessing@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>> Den man. 12. aug. 2019 kl. 15.15 skrev Ethan Li < >>>>>>>>>>>>>> ethanopensource@gmail.com>: >>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> Just in case if anyone happens to know the answer: >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> 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 ran >>>>>>>>>>>>>> =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? >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> I am currently blocked on this. Any help will be >>>>>> appreciated. >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> On Aug 12, 2019, at 2:38 AM, Stig Rohde D=C3=B8ssin= g < >>>>>>>>>>>>>> stigdoessing@gmail.com> >>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Sounds good Ethan. >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> 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 = separate >>>>>>>>>>>>>> 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 = Downloads >>>>>> page >>>>>>>>>>>>>> or a new >>>>>>>>>>>>>>>>>>>>>> page on the Storm site? >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>> Den s=C3=B8n. 11. aug. 2019 kl. 08.37 skrev Ethan = Li < >>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>: >>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> I am doing the release following >>>>>>>>>>>>>>>>>>>>>>> = https://github.com/apache/storm/blob/master/RELEASING.md >>>>>> < >>>>>>>>>>>>>>>>>>>>>>> = https://github.com/apache/storm/blob/master/RELEASING.md> >>>>>> . I >>>>>>>>>>>>>> made some >>>>>>>>>>>>>>>>>>>>>>> progress but I have some questions so I just = sent an >>>>>> email to >>>>>>>>>>>>>> Taylor. >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> Please don=E2=80=99t merge anything to master or = 2.1.x-branch >>>>>> for now. >>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>> Best, >>>>>>>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> On Aug 9, 2019, at 4:45 PM, Ethan Li < >>>>>>>>>>>>>> ethanopensource@gmail.com> >>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> Currently we have two outstanding PRs that we = wanted to >>>>>>>>>>>>>> include in the >>>>>>>>>>>>>>>>>>>>>>> new release: >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> 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.) >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> For the release, I will create a new branch = 2.1.x-branch >>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>> On Aug 9, 2019, at 2:53 PM, Derek Dagit < >>>>>> dagit@apache.org >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> dagit@apache.org>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>> That makes sense. It seems better for us not = to choose >>>>>> a >>>>>>>>>>>>>> specific >>>>>>>>>>>>>>>>>>>>>>>>> calendar date or duration of time. >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>> - We do not want too many release lines = supported >>>>>>>>>>>>>> concurrently. >>>>>>>>>>>>>>>>>>>>>>>>> - We want devs and users to know what to = expect. >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>> Derek >>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 09, 2019 at 10:32:59AM -0500, = Ethan Li >>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> Derek, >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 9, 2019, at 8:53 AM, Derek Dagit < >>>>>> dagit@apache.org >>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> dagit@apache.org>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 09, 2019 at 02:35:57PM +0200, = Stig Rohde >>>>>>>>>>>>>> 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, >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> This is a better link: >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> = https://cwiki.apache.org/confluence/display/TS/Release+Management >>>>>> < >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>> = https://cwiki.apache.org/confluence/display/TS/Release+Management >>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> This example, where "RM" means "Release = Manager": >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>> 1. We promise to make 1 major release / = year, but >>>>>> the RM >>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>> community >>>>>>>>>>>>>>>>>>>>>>>>>>>> can of course make more as necessary >>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>> 2. We only make releases off the LTS = branches, >>>>>> which are >>>>>>>>>>>>>> cut once a >>>>>>>>>>>>>>>>>>>>>>>>>>>> year off master >>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>> 3. Master is always open, for any type of = change >>>>>>>>>>> (including >>>>>>>>>>>>>>>>>>>>>>>>>>>> incompatible changes). But don't break >>>>>> compatibility just >>>>>>>>>>>>>> for fun! >>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>> 4. Master is always stable, i.e. commits = should be >>>>>>>>>>>>>> properly tested >>>>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewed before committed to master. >>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>> 5. All releases are stable releases, = following >>>>>> strict >>>>>>>>>>>>>> Semantic >>>>>>>>>>>>>>>>>>>>>>>>>>>> Versioning. >>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>> 6. Minor releases are made at the = discretion at the >>>>>>>>>>>>>> discretion of >>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>> community and the RM. >>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>> 7. Minor releases can include new (small / = safe) >>>>>>>>>>> features, >>>>>>>>>>>>>> but must >>>>>>>>>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>>>>>>>>>>> compatible within the LTS major version. >>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>> 8. The LTS cycle, 2 years + 6 months = Sunset, does >>>>>> not >>>>>>>>>>>>>> reset when we >>>>>>>>>>>>>>>>>>>>>>>>>>>> make a minor release. >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> Now, I am not proposing we do exactly this. = The goal >>>>>> would >>>>>>>>>>>>>> be to set >>>>>>>>>>>>>>>>>>>>>>>>>>> expectations among developers and the = community, and >>>>>> here >>>>>>>>>>>>>> is one >>>>>>>>>>>>>>>>>>>>>>>>>>> concrete example of how it could be done. >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 major >>>>>>>>>>>>>> version level >>>>>>>>>>>>>>>>>>>>>>>>>>>> only >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 9. aug. 2019 kl. 00.15 skrev Derek = Dagit < >>>>>>>>>>>>>>>>>>>>> dagit@apache.org >>>>>>>>>>>>>>>>>>>>>>> >: >>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> What do we think about defining Long-Term = Support >>>>>>>>>>>>>> branches with a >>>>>>>>>>>>>>>>>>>>>>> fixed >>>>>>>>>>>>>>>>>>>>>>>>>>>>> period of support? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> For example, we could say 2.0.x is an LTS = release >>>>>> line >>>>>>>>>>>>>> with >>>>>>>>>>>>>>>>>>>>> support >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ending no earlier than a certain calendar = date. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 = mentioned >>>>>>>>>>> earlier >>>>>>>>>>>>>>>>>>>>>>>>>>>>> (https://semver.org/ = ). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Apache Traffic Server does something like = this, to >>>>>> name >>>>>>>>>>>>>> one >>>>>>>>>>>>>>>>>>>>> project: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://trafficserver.apache.org/downloads = < >>>>>>>>>>>>>>>>>>>>>>> https://trafficserver.apache.org/downloads> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Having a regular cadence of releases might = also >>>>>> help >>>>>>>>>>> make >>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>> process >>>>>>>>>>>>>>>>>>>>>>>>>>>>> easier and help set expectations for users = and >>>>>> devs. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Derek >>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Aug 08, 2019 at 02:50:07PM -0500, = Ethan Li >>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Currently we don=E2=80=99t have a = 2.0.x-branch and master >>>>>> is >>>>>>>>>>>>>> actually >>>>>>>>>>>>>>>>>>>>>>>>>>>>> =E2=80=9C2.0.1-SNAPSHOT=E2=80=9D. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But we will have one problem: we will = lose 2.0.x >>>>>>>>>>> release >>>>>>>>>>>>>> line. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are two things I can do: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1) create a 2.0.x-branch based on v2.0.0 = tag. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2) ignore it. If there is an issue with = 2.0.x >>>>>> release, >>>>>>>>>>>>>> ask users >>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>>>>> upgrade to 2.1.0. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I prefer 1) but not sure if it=E2=80=99s = the right way to >>>>>> make >>>>>>>>>>>>>> things >>>>>>>>>>>>>>>>>>>>>>> right. Or >>>>>>>>>>>>>>>>>>>>>>>>>>>>> please let me know if I misunderstood = something >>>>>> and it=E2=80=99s >>>>>>>>>>>>>> not an >>>>>>>>>>>>>>>>>>>>>>> issue. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:43 AM, Ethan Li < >>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde = D=C3=B8ssing >>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great. Remember to add your key = to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den ons. 7. aug. 2019 kl. 15.05 skrev = Ethan Li < >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. = Call < >>>>>>>>>>>>>> bcall@apache.org >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bcall@apache.org>> (Thanks to him). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My pgp key: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>> = http://pgp.surfnet.nl/pks/lookup?op=3Dvindex&fingerprint=3Don&search=3D0xA= 4A672F11B5050C8 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>> = http://pgp.surfnet.nl/pks/lookup?op=3Dvindex&fingerprint=3Don&search=3D0xA= 4A672F11B5050C8 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My understanding is that I am good to = do >>>>>> release >>>>>>>>>>> with >>>>>>>>>>>>>> this key >>>>>>>>>>>>>>>>>>>>>>> now. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Here is a list of PRs that we might = want to >>>>>> include >>>>>>>>>>>>>> in the new >>>>>>>>>>>>>>>>>>>>>>>>>>>>> release: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> = 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> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please review if you get a chance. = Thanks >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 1, 2019, at 4:19 AM, Stig = Rohde >>>>>> D=C3=B8ssing < >>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 = skrev Ethan >>>>>> Li < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It=E2=80=99s a good point. I will = start a discussion >>>>>>>>>>> thread >>>>>>>>>>>>>> for it. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For the new release, I went through = the list: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>> = https://issues.apache.org/jira/issues/?jql=3Dproject%20%3D%20STORM%20AND%2= 0fixVersion%20%3D%202.0.1 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>> = https://issues.apache.org/jira/issues/?jql=3Dproject%20=3D%20STORM%20AND%2= 0fixVersion%20=3D%202.0.1 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We introduced some new = functionalities, >>>>>> including >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>> https://issues.apache.org/jira/browse/STORM-2720 >>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>> https://issues.apache.org/jira/browse/STORM-2720> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>> https://issues.apache.org/jira/browse/STORM-3412 >>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>> https://issues.apache.org/jira/browse/STORM-3412> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>> https://issues.apache.org/jira/browse/STORM-3411 >>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>> https://issues.apache.org/jira/browse/STORM-3411> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>> https://issues.apache.org/jira/browse/STORM-3442 >>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>> https://issues.apache.org/jira/browse/STORM-3442> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>> https://issues.apache.org/jira/browse/STORM-3396 >>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>> https://issues.apache.org/jira/browse/STORM-3396> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>> https://issues.apache.org/jira/browse/STORM-3392 >>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>> https://issues.apache.org/jira/browse/STORM-3392> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>> https://issues.apache.org/jira/browse/STORM-3395 >>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>> https://issues.apache.org/jira/browse/STORM-3395> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So I think we should release 2.1.0 = rather >>>>>> than >>>>>>>>>>>>>> 2.0.1. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are a few pull requests we may = want to >>>>>>>>>>> review >>>>>>>>>>>>>> before >>>>>>>>>>>>>>>>>>>>>>> the next >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> = 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> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 29, 2019, at 10:11 AM, Hugo = Louro < >>>>>>>>>>>>>>>>>>>>> hmclouro@gmail.com >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hugo >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Jul 29, 2019 at 7:15 AM = Ethan Li < >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig = Rohde >>>>>>>>>>> D=C3=B8ssing < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Semver for binary compatibility = would >>>>>> probably >>>>>>>>>>>>>> be a good >>>>>>>>>>>>>>>>>>>>>>> rule of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thumb. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 20.01 = skrev >>>>>> Ethan >>>>>>>>>>> Li < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Stig, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Do you know what=E2=80=99s the = versioning >>>>>> standard we >>>>>>>>>>>>>> have been >>>>>>>>>>>>>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> determine a 2.0.1 release or = 2.1.0 >>>>>> release) ? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 12:26 PM, = Stig Rohde >>>>>>>>>>>>>> D=C3=B8ssing < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. = 19.16 skrev >>>>>> Ethan >>>>>>>>>>>>>> Li < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It=E2=80=99s good idea to do = more frequent >>>>>> release. >>>>>>>>>>> I >>>>>>>>>>>>>> can run >>>>>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>>>>> next >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I will take a look at both = PRs. Other >>>>>> than >>>>>>>>>>>>>> that, I >>>>>>>>>>>>>>>>>>>>>>> think we >>>>>>>>>>>>>>>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> also >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> get >>>>>>>>>>> https://github.com/apache/storm/pull/3093 >>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>> https://github.com/apache/storm/pull/3093> >>>>>>>>>>>>>> in the >>>>>>>>>>>>>>>>>>>>> new >>>>>>>>>>>>>>>>>>>>>>>>>>>>> release. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 11:58 AM, = Stig >>>>>> Rohde >>>>>>>>>>>>>> D=C3=B8ssing < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think we've talked about = more >>>>>> frequent >>>>>>>>>>>>>> releases >>>>>>>>>>>>>>>>>>>>>>> before. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Releasing >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> new >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> versions every few months = means people >>>>>>>>>>> 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 is >>>>>>>>>>>>>> enormous). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>> = https://issues.apache.org/jira/issues/?jql=3Dproject%20%3D%20STORM%20AND%2= 0fixVersion%20%3D%202.0.1 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Govind and Ethan have offered = to run >>>>>> the >>>>>>>>>>> next >>>>>>>>>>>>>>>>>>>>> release, >>>>>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>>>>>>>> help >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> validate >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> our release process = guidelines. Would >>>>>> one >>>>>>>>>>> of >>>>>>>>>>>>>> you have >>>>>>>>>>>>>>>>>>>>>>> time >>>>>>>>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> work >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release in the near future? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would like to see at least >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> = https://github.com/apache/storm/pull/2990 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> merged >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>> https://github.com/apache/storm/pull/2878 >>>>>>>>>>>>>> seems like >>>>>>>>>>>>>>>>>>>>>>> it's >>>>>>>>>>>>>>>>>>>>>>>>>>>>> close >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mergeable too? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_BF1A71AC-F893-45F5-BC15-8F8D100C3719--