From dev-return-60445-archive-asf-public=cust-asf.ponee.io@storm.apache.org Mon Aug 12 13:15:45 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 8501A180637 for ; Mon, 12 Aug 2019 15:15:45 +0200 (CEST) Received: (qmail 51537 invoked by uid 500); 12 Aug 2019 13:15:44 -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 51525 invoked by uid 99); 12 Aug 2019 13:15:44 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 12 Aug 2019 13:15:44 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 58B78C1CE2 for ; Mon, 12 Aug 2019 13:15:43 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.803 X-Spam-Level: ** X-Spam-Status: No, score=2.803 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, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-ec2-va.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id 9bBBil1ZgU6V for ; Mon, 12 Aug 2019 13:15:39 +0000 (UTC) Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=209.85.210.50; helo=mail-ot1-f50.google.com; envelope-from=ethanopensource@gmail.com; receiver= Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) by mx1-ec2-va.apache.org (ASF Mail Server at mx1-ec2-va.apache.org) with ESMTPS id 30803BC7B3 for ; Mon, 12 Aug 2019 13:15:39 +0000 (UTC) Received: by mail-ot1-f50.google.com with SMTP id m24so5496093otp.12 for ; Mon, 12 Aug 2019 06:15:39 -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=uKiTTXWOsm/y7sZRPycd3JxJv+IxsZf7SUU3y9Hd818=; b=Ldk7liGg2qrYYpK/xmpLt7X9eUdcuo7jNwEdAafPdcyREKNDMtV/PKjdjZWsb2POCr uc7PnWZCl6XkeqNrjsxSKKBTX9/Toei8YH8a6Ps7SpJaDM1i6tCZEIvuyPEVcZkS4Pva r40tp8b0PNaWeYlSd/0YdWZM6QUYfyFpxewIF4qOgDUqYE0pcjFZlaVi4va3Neq5HlGd HvSLCGkoQ2pCvemfTZI/bizc558iw6ORgCsAhhIJhqztXY3pDj3QC1aBSWEsCtLgtznx CqXLqVgljbHyJn4Iwd6XufMTI63ojkG3lqIfeScEdkyoGQjDLYcXTv90v2nkF7Nz5OWK x15Q== 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=uKiTTXWOsm/y7sZRPycd3JxJv+IxsZf7SUU3y9Hd818=; b=h3Z/zTW/e544GAg1Qn5IsLRkoyfXrtFyjYulGj/Fvr+9xLapzAfOAu5DRTYwjpwxhA kru7K/iLVE6k6POS0+ZLWaLYpcOCNkryqgTG7GiJ6JnrXOjNiotiIYyVCBSVVP+iEKw6 ZU2w079kg84Y4S43PZvYD9q41BovnymNIGVhg3MR3tQuIgtJJq49o6IEN/kzvntj3Ekv fSW3n8LtpXjWG7U0ZC2FO99jrCZBVpgfRvsS267NYSsA+WV/671vlSS0vv6/NZ/9Vf70 rlWHd3O/SxapDPwYBJcSUc5ytXxhgvCGIzkgjvTaFdSVWh2c9HLTLIQhtsrNVsv2Y+wK CHFw== X-Gm-Message-State: APjAAAWm0+3uWqHTB5ued82sLV+L4tLH0b32lZoej2bVohuabjLMSzCl VGd8on2eOrdFmjq0NE3zfDQsFgwD9QU= X-Google-Smtp-Source: APXvYqxUK3W/+zFDqtVK/s24aQHBI1kEDMGlgkSWIK9r3CPNvKdRWhjk4zRl7oahRf5PKxSn28Y7wQ== X-Received: by 2002:a5e:9319:: with SMTP id k25mr36755451iom.137.1565615738167; Mon, 12 Aug 2019 06:15:38 -0700 (PDT) Received: from ethans-mbp.home (hpnd-dhcp-173-46-246-244.bloombb.net. [173.46.246.244]) by smtp.gmail.com with ESMTPSA id j1sm90640779iop.14.2019.08.12.06.15.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 12 Aug 2019 06:15:37 -0700 (PDT) From: Ethan Li Content-Type: multipart/alternative; boundary="Apple-Mail=_E265C243-EDE3-4B1E-83B5-A44F9338B3DA" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: [DISCUSS] Next 2.x release Date: Mon, 12 Aug 2019 08:15:36 -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> To: dev@storm.apache.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.104.11) --Apple-Mail=_E265C243-EDE3-4B1E-83B5-A44F9338B3DA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Just in case if anyone happens to know the answer: I created a 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 = 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 = 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 = : >=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 = 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 >> 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: >> https://cwiki.apache.org/confluence/display/TS/Release+Management < >> 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 = > >: >>>>>>>=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 = >>>>>>>> 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 >>>>>>>>>>> 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>> (Thanks to him). >>>>>>>>>>>>=20 >>>>>>>>>>>> My pgp key: >>>>>>>>>>>>=20 >>>>>>>>=20 >> = http://pgp.surfnet.nl/pks/lookup?op=3Dvindex&fingerprint=3Don&search=3D0xA= 4A672F11B5050C8 >>>>>>>>>>>> < >>>>>>>>>>>>=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 >> = https://issues.apache.org/jira/issues/?jql=3Dproject%20%3D%20STORM%20AND%2= 0fixVersion%20%3D%202.0.1 >>>>>>>>>>>>>> < >>>>>>>>>>>>>>=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 = >>=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=B8ssin= g < >>>>>>>>>>>>>>>>>> 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 >> = 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 --Apple-Mail=_E265C243-EDE3-4B1E-83B5-A44F9338B3DA--