From dev-return-60467-archive-asf-public=cust-asf.ponee.io@storm.apache.org Tue Aug 13 16:20:02 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 6B7DF18064D for ; Tue, 13 Aug 2019 18:20:02 +0200 (CEST) Received: (qmail 28999 invoked by uid 500); 13 Aug 2019 16:20:01 -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 28902 invoked by uid 99); 13 Aug 2019 16:20:01 -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:20:01 +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 87289C0A2B for ; Tue, 13 Aug 2019 16:20:00 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.601 X-Spam-Level: * X-Spam-Status: No, score=1.601 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, FREEMAIL_REPLY=1, KAM_ASCII_DIVIDERS=0.8, 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 a-Y3fx7W2Vra for ; Tue, 13 Aug 2019 16:19:56 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=2607:f8b0:4864:20::82f; helo=mail-qt1-x82f.google.com; envelope-from=ptgoetz@gmail.com; receiver= Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) by mx1-he-de.apache.org (ASF Mail Server at mx1-he-de.apache.org) with ESMTPS id B7B067D3FB for ; Tue, 13 Aug 2019 16:19:55 +0000 (UTC) Received: by mail-qt1-x82f.google.com with SMTP id u34so7615488qte.2 for ; Tue, 13 Aug 2019 09:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=0EJ6qJRLpBkkmEBm8xY61ZiPxEikS5yxufkVMsNTXS8=; b=D93GXe2PiU5E2Ky6kcka/1F14WBatAUDMfgqOGkT7FqXb3YcRBsjuL1UaflX6MrDaq B2NQXpOcO3lroHFfuviJIDo5hF0NKEemxsOtbDwhA8dODGtsdUFInhCRZbfS2E+sFLkg lHHwLHrxWq8fc8ScxyT4y2HzHFZ19ygojlC2iMBf1EMnoW49NBSViLvxWzryq9atxvpm 1sjU8CDoNUKc2DJfOfhrBThS4s/UE1zV4Z8Rbh3IPzepiUesDmGVa6pVF8gj7ANlcirN jCk/q692iIE9Hgs2rFoZdaI1fm8WwJRaGTpSkMqzMOHsi0MWxNnhU+kX7hX2gBrB8X5P +ouA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=0EJ6qJRLpBkkmEBm8xY61ZiPxEikS5yxufkVMsNTXS8=; b=RokYecROMMn7s2Ep28r8Jhio1p99TgbIBeIjG2ZmmDZ7sUHEkPgTWNM5x+XkO1N/A6 YqmlV1Tts8X8DUyY5p/ggzzyhTgjUgHgkfDzIBvTIq8/BqzSQ9jo0xbwLEZjK8ygIuy7 c+HbwDYSqTAW2eEdL9sUQp6usOiU3bhjGk60FNgbGBrxWrnPMePu7b4UrqnxZp91pjzT cFnqeeO6PuFEw2bN6LR00/h0+ET+hlMc0fQr3v6NKK+eI2Z91uTeE9MPcwLZlOP9YHuk wk0lpOEeHTn2VvxUwgx4e3trQt5FAhk/iuKYn2jBW7V/4x07Svr+TeC+nV+V9U9cohzI GbDw== X-Gm-Message-State: APjAAAX9qI1wbXylc8vK7nbhVwbvBNS14QYWwQRY2/zxUferMYCHIYCk RGXMuSYssiVkj6EDiYI46y63luPV X-Google-Smtp-Source: APXvYqxbBzq6isL961PNFLzIeWfnrz0HXMuaujQ9le7lEg5j1HDYhTXaJ56O8io0WLSeLcqZnXyayQ== X-Received: by 2002:a0c:f482:: with SMTP id i2mr34939970qvm.233.1565713188516; Tue, 13 Aug 2019 09:19:48 -0700 (PDT) Received: from [172.25.1.129] (50-77-83-173-static.hfc.comcastbusiness.net. [50.77.83.173]) by smtp.gmail.com with ESMTPSA id i74sm11917202qke.133.2019.08.13.09.19.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Aug 2019 09:19:47 -0700 (PDT) From: "P. Taylor Goetz" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: [DISCUSS] Next 2.x release Date: Tue, 13 Aug 2019 12:19:46 -0400 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> To: dev@storm.apache.org In-Reply-To: <12816261-1B8D-4196-9C3E-337ECFE6EB24@gmail.com> Message-Id: <2055B111-7BFF-47E8-A92E-F5C6781DDBB6@gmail.com> X-Mailer: Apple Mail (2.3445.104.11) Those can be safely deleted. -Taylor > 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 = ? >=20 > = 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/ = >=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 = 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 = : >>>=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=9Cm= vn >>>> 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 = >>>> 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=B8ssing < >>>>> 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 = >>>>>>> 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 = >>>>>>> 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 = >>>>>>> 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 >>>> = https://git-wip-us.apache.org/repos/asf?p=3Dstorm.git;a=3Dblob_plain;f=3DK= EYS;hb=3D22b832708295fa2c15c4f3c70ac0d2bc6fded4bd >>>>>>> < >>>>>>>=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 = >>>>>>> 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 = >>>>>>> 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=B8ssing < >>>>>>> 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>> 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>> 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 >>>>>>>>>>>>>>>>>>>> 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 >>>> = http://pgp.surfnet.nl/pks/lookup?op=3Dvindex&fingerprint=3Don&search=3D0xA= 4A672F11B5050C8 >>>>>>>>>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>=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 >>>> = 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 >>>> = 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 >>>>>>>>>>>>>>>>>>>>>>>>>>>> = 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> >>>>>>>>>>>>>>>>>>>>>>>>>>>>=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 >>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> = 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 >>>> = 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 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> = 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