Hi Taylor, Mostly I was able to follow the doc https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>, except:
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 For Step3, I had to run "git checkout tags/v2.1.0 -b v2.1.0” so that I can run “mvn package” for storm-dist/binary and storm-dist/source based on v2.1.0. Otherwise if I run “mvn package” on 2.1.x-branch, it will fail because the pom version is “2.1.x-SNAPSHOT”. 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. 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! Ethan > On Aug 14, 2019, at 12:24 PM, Ethan Li <ethanopensou...@gmail.com> wrote: > > I am continuing for another release candidate since the pr is merged. > >> On Aug 13, 2019, at 11:58 AM, Stig Rohde Døssing <stigdoess...@gmail.com> >> wrote: >> >> Updated https://github.com/apache/storm/pull/3053 so we don't have >> org.apache.storm artifacts in the DEPENDENCY-LICENSES file. It's ready for >> review if someone wants to look at it. >> >> Den tir. 13. aug. 2019 kl. 18.21 skrev Ethan Li <ethanopensou...@gmail.com>: >> >>> Thank you, Taylor. Will delete them. >>> >>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <ptgo...@gmail.com> wrote: >>>> >>>> Those can be safely deleted. >>>> >>>> -Taylor >>>> >>>>> On Aug 13, 2019, at 12:15 PM, Ethan Li <ethanopensou...@gmail.com> >>> wrote: >>>>> >>>>> Do we need/want to clean up the release candidate from >>> https://dist.apache.org/repos/dist/dev/storm < >>> https://dist.apache.org/repos/dist/dev/storm> ? >>>>> >>>>> >>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails >>> < >>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails> >>> says we do. But we have a lot of rc in >>> https://dist.apache.org/repos/dist/dev/storm/ < >>> https://dist.apache.org/repos/dist/dev/storm/> >>>>> >>>>> Just want to be absolutely sure about this. Thanks. >>>>> >>>>>> On Aug 13, 2019, at 10:56 AM, Ethan Li <ethanopensou...@gmail.com> >>> wrote: >>>>>> >>>>>> That sounds better. It will be easier for release. Thank you for >>> looking into this. >>>>>> >>>>>>> On Aug 13, 2019, at 10:54 AM, Stig Rohde Døssing < >>> stigdoess...@gmail.com> wrote: >>>>>>> >>>>>>> Makes sense. I'll take a look at it. Ideally I'd want the license >>> files to >>>>>>> just not include org.apache.storm artifacts. I don't think we need to >>> tell >>>>>>> people that the project depends on itself. >>>>>>> >>>>>>> If we can exclude these artifacts from the lists, I don't think the >>> release >>>>>>> plugin needs to update these files. >>>>>>> >>>>>>> Den tir. 13. aug. 2019 kl. 17.36 skrev Ethan Li < >>> ethanopensou...@gmail.com>: >>>>>>> >>>>>>>> Thanks Stig. >>>>>>>> >>>>>>>> In this case, we probably should abort release process and get this >>> merged >>>>>>>> into master first. Also we need to make sure it works with “mvn >>>>>>>> release:prepare” since “ mvn release:prepare” will automatically >>> push two >>>>>>>> commits. For example, >>>>>>>> >>>>>>>> (1) [maven-release-plugin] prepare release v2.1.0: this commit >>> changes >>>>>>>> the pom version to 2.1.0, push the commit, and then create a git tag >>> v2.1.0. >>>>>>>> >>>>>>>> (2) [maven-release-plugin] prepare for next development iteration: >>> this >>>>>>>> commit changes the pom version to 2.1.1-SNAPSHOT. >>>>>>>> >>>>>>>> >>>>>>>> We need DEPENDENCY-LICENSES to be updated on every step. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On Aug 13, 2019, at 10:24 AM, Stig Rohde Døssing < >>> stigdoess...@gmail.com> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>> 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. >>>>>>>>> >>>>>>>>> Den tir. 13. aug. 2019 kl. 17.15 skrev Stig Rohde Døssing < >>>>>>>>> stigdoess...@gmail.com>: >>>>>>>>> >>>>>>>>>> There's a script that can help you do it in >>>>>>>>>> https://github.com/apache/storm/pull/3053. It checks the >>>>>>>>>> DEPENDENCY-LICENSES and LICENSE-binary contain the right >>> dependencies, >>>>>>>> and >>>>>>>>>> prints which licenses are redundant or should be added. >>>>>>>>>> >>>>>>>>>> For DEPENDENCY-LICENSES specifically you can run "mvn >>>>>>>>>> license:aggregate-add-third-party@generate-and-check-licenses >>>>>>>>>> -Dlicense.skipAggregateAddThirdParty=false -B" in the project >>> root. It >>>>>>>>>> should update the file for you. >>>>>>>>>> >>>>>>>>>> Den tir. 13. aug. 2019 kl. 17.06 skrev Ethan Li < >>>>>>>> ethanopensou...@gmail.com >>>>>>>>>>> : >>>>>>>>>> >>>>>>>>>>> Hi Stig, >>>>>>>>>>> >>>>>>>>>>> How do we update >>>>>>>>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? >>> < >>>>>>>>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> >>> Is >>>>>>>>>>> there a command I can use? Or I just replace strings manually? >>>>>>>>>>> >>>>>>>>>>> Thanks >>>>>>>>>>> Ethan >>>>>>>>>>> >>>>>>>>>>>> On Aug 12, 2019, at 3:54 PM, Ethan Li <ethanopensou...@gmail.com >>>> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Yes my public keys in that file. Thanks! Ready to set up a vote. >>>>>>>>>>>> >>>>>>>>>>>>> On Aug 12, 2019, at 3:52 PM, P. Taylor Goetz <ptgo...@gmail.com >>>> >>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Yes. Is you public key in that file? If not you should add it. >>>>>>>>>>>>> >>>>>>>>>>>>> -Taylor >>>>>>>>>>>>> >>>>>>>>>>>>>> On Aug 12, 2019, at 4:15 PM, Ethan Li < >>> ethanopensou...@gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have one more question before I can start a vote. >>>>>>>>>>>>>> >>>>>>>>>>>>>> In previous [VOTE] thread, Taylor always has this: >>>>>>>>>>>>>> >>>>>>>>>>>>>> The release artifacts are signed with the following key: >>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd >>>>>>>>>>> < >>>>>>>>>>> >>>>>>>> >>> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd >>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Does anyone know where to find the updated KEYs file? Should I >>> just >>>>>>>>>>> use https://www.apache.org/dist/storm/KEYS < >>>>>>>>>>> https://www.apache.org/dist/storm/KEYS> ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks very much >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Aug 12, 2019, at 9:44 AM, Ethan Li < >>> ethanopensou...@gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks Stig and Taylor! It worked. I will continue the >>> process now >>>>>>>>>>> and update the documentation later. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Aug 12, 2019, at 9:40 AM, P. Taylor Goetz < >>> ptgo...@gmail.com> >>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 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: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -P dist,include-shaded-deps,rat,externals,examples >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Taylor >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Aug 12, 2019, at 9:27 AM, Stig Rohde Døssing < >>>>>>>>>>> stigdoess...@gmail.com> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Try enabling the "dist" profile by adding "-P >>>>>>>>>>> dist,externals,examples" to >>>>>>>>>>>>>>>>> the command you're running. See >>>>>>>>>>>>>>>>> https://github.com/apache/storm/blob/master/pom.xml#L518. >>> Unless >>>>>>>>>>> you enable >>>>>>>>>>>>>>>>> that profile, the storm-dist modules aren't in the reactor. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Den man. 12. aug. 2019 kl. 15.15 skrev Ethan Li < >>>>>>>>>>> ethanopensou...@gmail.com>: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Just in case if anyone happens to know the answer: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I created a branch >>>>>>>>>>> https://github.com/apache/storm/tree/2.1.x-branch < >>>>>>>>>>>>>>>>>> https://github.com/apache/storm/tree/2.1.x-branch> and ran >>>>>>>>>>> “mvn:prepare” >>>>>>>>>>>>>>>>>> and “mvn:perform”. 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’s >>>>>>>>>>>>>>>>>> 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 “mvn:prepare” step. How >>> do I >>>>>>>>>>> get >>>>>>>>>>>>>>>>>> storm-dist pom version updated with “mv:prepare”? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I am currently blocked on this. Any help will be >>> appreciated. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Aug 12, 2019, at 2:38 AM, Stig Rohde Døssing < >>>>>>>>>>> stigdoess...@gmail.com> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Sounds good Ethan. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Derek, I also think being clear about how long we expect >>> to >>>>>>>>>>> support a >>>>>>>>>>>>>>>>>>> release line is a good idea. Maybe we should do a 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? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Den søn. 11. aug. 2019 kl. 08.37 skrev Ethan Li < >>>>>>>>>>>>>>>>>> ethanopensou...@gmail.com>: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 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. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Please don’t merge anything to master or 2.1.x-branch >>> for now. >>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Best, >>>>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Aug 9, 2019, at 4:45 PM, Ethan Li < >>>>>>>>>>> ethanopensou...@gmail.com> >>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Currently we have two outstanding PRs that we wanted to >>>>>>>>>>> include in the >>>>>>>>>>>>>>>>>>>> new release: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3096 < >>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3096> (Travis has >>> some >>>>>>>>>>> issues >>>>>>>>>>>>>>>>>>>> connecting to repository.apache.org < >>>>>>>>>>> http://repository.apache.org/> >>>>>>>>>>>>>>>>>>>> recently. Travis build fails consistently) >>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878 < >>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878> (Some >>> comments are >>>>>>>>>>> to be >>>>>>>>>>>>>>>>>>>> addressed but Author hasn’t responded yet.) >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> It’s not absolutely necessary to include them in this >>> new >>>>>>>>>>> release so I >>>>>>>>>>>>>>>>>>>> think I should move forward with the release process. >>> These >>>>>>>> two >>>>>>>>>>> and >>>>>>>>>>>>>>>>>> other >>>>>>>>>>>>>>>>>>>> PRs can be included in the next release. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> For the release, I will create a new branch 2.1.x-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. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Aug 9, 2019, at 2:53 PM, Derek Dagit < >>> da...@apache.org >>>>>>>>>>> <mailto: >>>>>>>>>>>>>>>>>>>> da...@apache.org>> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> We might not able to say how long we want to support a >>>>>>>>>>> specific >>>>>>>>>>>>>>>>>>>>>>> release line but I would love to see a clear release >>> policy >>>>>>>>>>> being >>>>>>>>>>>>>>>>>>>>>>> made. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> That makes sense. It seems better for us not to choose >>> a >>>>>>>>>>> specific >>>>>>>>>>>>>>>>>>>>>> calendar date or duration of time. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> - We do not want too many release lines supported >>>>>>>>>>> concurrently. >>>>>>>>>>>>>>>>>>>>>> - We want devs and users to know what to expect. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>> Derek >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 09, 2019 at 10:32:59AM -0500, Ethan Li >>> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Derek, >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I think it’s a good idea to be more clear on the >>> versioning >>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>> release process so users and developers know what to >>> expect. >>>>>>>> We >>>>>>>>>>> might >>>>>>>>>>>>>>>>>> not >>>>>>>>>>>>>>>>>>>> able to say how long we want to support a specific >>> release >>>>>>>> line >>>>>>>>>>> but I >>>>>>>>>>>>>>>>>> would >>>>>>>>>>>>>>>>>>>> love to see a clear release policy being made. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Aug 9, 2019, at 8:53 AM, Derek Dagit < >>> da...@apache.org >>>>>>>>>>> <mailto: >>>>>>>>>>>>>>>>>>>> da...@apache.org>> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 09, 2019 at 02:35:57PM +0200, Stig Rohde >>>>>>>>>>> Døssing wrote: >>>>>>>>>>>>>>>>>>>>>>>>> Where on the Traffic Server page do they list how >>> long >>>>>>>>>>> their >>>>>>>>>>>>>>>>>> release >>>>>>>>>>>>>>>>>>>>>>>>> trains survive? I only see dates of release, not >>> how long >>>>>>>>>>> e.g. 7.x >>>>>>>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>>>>>>> supposed to receive support. Derek, >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> This is a better link: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> https://cwiki.apache.org/confluence/display/TS/Release+Management >>> < >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>> https://cwiki.apache.org/confluence/display/TS/Release+Management >>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> This example, where "RM" means "Release Manager": >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> 1. We promise to make 1 major release / year, but >>> the RM >>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>> community >>>>>>>>>>>>>>>>>>>>>>>>> can of course make more as necessary >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> 2. We only make releases off the LTS branches, >>> which are >>>>>>>>>>> cut once a >>>>>>>>>>>>>>>>>>>>>>>>> year off master >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> 3. Master is always open, for any type of change >>>>>>>> (including >>>>>>>>>>>>>>>>>>>>>>>>> incompatible changes). But don't break >>> compatibility just >>>>>>>>>>> for fun! >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> 4. Master is always stable, i.e. commits should be >>>>>>>>>>> properly tested >>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>>>> reviewed before committed to master. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> 5. All releases are stable releases, following >>> strict >>>>>>>>>>> Semantic >>>>>>>>>>>>>>>>>>>>>>>>> Versioning. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> 6. Minor releases are made at the discretion at the >>>>>>>>>>> discretion of >>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>> community and the RM. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> 7. Minor releases can include new (small / safe) >>>>>>>> features, >>>>>>>>>>> but must >>>>>>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>>>>>>>> compatible within the LTS major version. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> 8. The LTS cycle, 2 years + 6 months Sunset, does >>> not >>>>>>>>>>> reset when we >>>>>>>>>>>>>>>>>>>>>>>>> make a minor release. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Now, I am not proposing we do exactly this. The goal >>> would >>>>>>>>>>> be to set >>>>>>>>>>>>>>>>>>>>>>>> expectations among developers and the community, and >>> here >>>>>>>>>>> is one >>>>>>>>>>>>>>>>>>>>>>>> concrete example of how it could be done. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> If we're going to promise that a release line >>> survives >>>>>>>> for >>>>>>>>>>> a given >>>>>>>>>>>>>>>>>>>>>>>>> amount of time, I think we should do it at the major >>>>>>>>>>> version level >>>>>>>>>>>>>>>>>>>>>>>>> only >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Yeah, that sounds reasonable to me. If we choose to >>> commit >>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>> something >>>>>>>>>>>>>>>>>>>>>>>> like the above, we should base the decision in part >>> on >>>>>>>> what >>>>>>>>>>> kind of >>>>>>>>>>>>>>>>>>>>>>>> resources we have so that we do not over-commit. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 9. aug. 2019 kl. 00.15 skrev Derek Dagit < >>>>>>>>>>>>>>>>>> da...@apache.org >>>>>>>>>>>>>>>>>>>> <mailto:da...@apache.org>>: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> What do we think about defining Long-Term Support >>>>>>>>>>> branches with a >>>>>>>>>>>>>>>>>>>> fixed >>>>>>>>>>>>>>>>>>>>>>>>>> period of support? >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> For example, we could say 2.0.x is an LTS release >>> line >>>>>>>>>>> with >>>>>>>>>>>>>>>>>> support >>>>>>>>>>>>>>>>>>>>>>>>>> ending no earlier than a certain calendar date. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> The date could be extended, and it might >>> ultimately be >>>>>>>>>>> governed by >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>> timing of the subsequent release (e.g., 2.1.x or >>> 3.0.x). >>>>>>>>>>> Keeping >>>>>>>>>>>>>>>>>>>> things >>>>>>>>>>>>>>>>>>>>>>>>>> clear would imply semantic versioning as mentioned >>>>>>>> earlier >>>>>>>>>>>>>>>>>>>>>>>>>> (https://semver.org/ <https://semver.org/>). >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Apache Traffic Server does something like this, to >>> name >>>>>>>>>>> one >>>>>>>>>>>>>>>>>> project: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> https://trafficserver.apache.org/downloads < >>>>>>>>>>>>>>>>>>>> https://trafficserver.apache.org/downloads> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Having a regular cadence of releases might also >>> help >>>>>>>> make >>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> process >>>>>>>>>>>>>>>>>>>>>>>>>> easier and help set expectations for users and >>> devs. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>>>>>>> Derek >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Aug 08, 2019 at 02:50:07PM -0500, Ethan Li >>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Currently we don’t have a 2.0.x-branch and master >>> is >>>>>>>>>>> actually >>>>>>>>>>>>>>>>>>>>>>>>>> “2.0.1-SNAPSHOT”. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>>>>>>>> “2.2.0-SNAPSHOT”. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> But we will have one problem: we will lose 2.0.x >>>>>>>> release >>>>>>>>>>> line. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> There are two things I can do: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> 1) create a 2.0.x-branch based on v2.0.0 tag. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> 2) ignore it. If there is an issue with 2.0.x >>> release, >>>>>>>>>>> ask users >>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>> upgrade to 2.1.0. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> I prefer 1) but not sure if it’s the right way to >>> make >>>>>>>>>>> things >>>>>>>>>>>>>>>>>>>> right. Or >>>>>>>>>>>>>>>>>>>>>>>>>> please let me know if I misunderstood something >>> and it’s >>>>>>>>>>> not an >>>>>>>>>>>>>>>>>>>> issue. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Btw, I am seeing the same issue with 1.x-branch. >>> We >>>>>>>>>>> shouldn’t >>>>>>>>>>>>>>>>>> have >>>>>>>>>>>>>>>>>>>>>>>>>> 1.x-branch. Instead, we should have 1.2.x-branch. >>> But >>>>>>>>>>> this is not >>>>>>>>>>>>>>>>>> a >>>>>>>>>>>>>>>>>>>> problem >>>>>>>>>>>>>>>>>>>>>>>>>> since we will not release 1.3.x. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:43 AM, Ethan Li < >>>>>>>>>>>>>>>>>> ethanopensou...@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing >>> < >>>>>>>>>>>>>>>>>>>>>>>>>> stigdoess...@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great. Remember to add your key to >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>> https://dist.apache.org/repos/dist/release/storm/KEYS, >>>>>>>>>>> you >>>>>>>>>>>>>>>>>>>> should be >>>>>>>>>>>>>>>>>>>>>>>>>> able >>>>>>>>>>>>>>>>>>>>>>>>>>>>> to update it with an SVN client. See also >>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://www.apache.org/dev/openpgp.html#update. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den ons. 7. aug. 2019 kl. 15.05 skrev Ethan Li < >>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensou...@gmail.com>: >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call < >>>>>>>>>>> bc...@apache.org >>>>>>>>>>>>>>>>>>>> <mailto: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bc...@apache.org>> (Thanks to him). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My pgp key: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>> http://pgp.surfnet.nl/pks/lookup?op=vindex&fingerprint=on&search=0xA4A672F11B5050C8 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>> http://pgp.surfnet.nl/pks/lookup?op=vindex&fingerprint=on&search=0xA4A672F11B5050C8 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My understanding is that I am good to do >>> release >>>>>>>> with >>>>>>>>>>> this key >>>>>>>>>>>>>>>>>>>> now. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Here is a list of PRs that we might want to >>> include >>>>>>>>>>> in the new >>>>>>>>>>>>>>>>>>>>>>>>>> release: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3098 < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3098> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3096 < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3096> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878 < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please review if you get a chance. Thanks >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 1, 2019, at 4:19 AM, Stig Rohde >>> Døssing < >>>>>>>>>>>>>>>>>>>>>>>>>> stigdoess...@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan >>> Li < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensou...@gmail.com>: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It’s a good point. I will start a discussion >>>>>>>> thread >>>>>>>>>>> for it. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For the new release, I went through the list: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>> https://issues.apache.org/jira/issues/?jql=project%20=%20STORM%20AND%20fixVersion%20=%202.0.1 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We introduced some new functionalities, >>> including >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> https://issues.apache.org/jira/browse/STORM-2720 >>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> https://issues.apache.org/jira/browse/STORM-2720> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> https://issues.apache.org/jira/browse/STORM-3412 >>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> https://issues.apache.org/jira/browse/STORM-3412> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> https://issues.apache.org/jira/browse/STORM-3411 >>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> https://issues.apache.org/jira/browse/STORM-3411> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> https://issues.apache.org/jira/browse/STORM-3442 >>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> https://issues.apache.org/jira/browse/STORM-3442> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> https://issues.apache.org/jira/browse/STORM-3396 >>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> https://issues.apache.org/jira/browse/STORM-3396> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> https://issues.apache.org/jira/browse/STORM-3392 >>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> https://issues.apache.org/jira/browse/STORM-3392> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> https://issues.apache.org/jira/browse/STORM-3395 >>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> https://issues.apache.org/jira/browse/STORM-3395> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So I think we should release 2.1.0 rather >>> than >>>>>>>>>>> 2.0.1. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are a few pull requests we may want to >>>>>>>> review >>>>>>>>>>> before >>>>>>>>>>>>>>>>>>>> the next >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3094 < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3094> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2990 < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2990> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878 < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 29, 2019, at 10:11 AM, Hugo Louro < >>>>>>>>>>>>>>>>>> hmclo...@gmail.com >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think it would facilitate more frequent >>>>>>>> releases >>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>> summarize >>>>>>>>>>>>>>>>>>>>>>>>>> in a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> page >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the testing that all >>> contributors/committers do >>>>>>>> in >>>>>>>>>>>>>>>>>>>> anticipation >>>>>>>>>>>>>>>>>>>>>>>>>> of the >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release, plus any "new" testing that may >>> become >>>>>>>>>>> relevant >>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>> newer >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> releases. Doing so would make it easy to >>> create a >>>>>>>>>>> check >>>>>>>>>>>>>>>>>> form >>>>>>>>>>>>>>>>>>>> or or >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> email >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> template that what we feel should be done to >>>>>>>>>>> guarantee a >>>>>>>>>>>>>>>>>>>> stable >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hugo >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Jul 29, 2019 at 7:15 AM Ethan Li < >>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensou...@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde >>>>>>>> Døssing < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoess...@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think ideally we've been trying for >>> semver, >>>>>>>>>>> but it's >>>>>>>>>>>>>>>>>> been >>>>>>>>>>>>>>>>>>>>>>>>>> pretty >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loose, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> e.g. there were breaking changes in one >>> of the >>>>>>>>>>> 1.2.x >>>>>>>>>>>>>>>>>>>> releases >>>>>>>>>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> storm-kafka-client. I don't know what >>> rules >>>>>>>> we've >>>>>>>>>>>>>>>>>> actually >>>>>>>>>>>>>>>>>>>> been >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> using, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> any. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Semver for binary compatibility would >>> probably >>>>>>>>>>> be a good >>>>>>>>>>>>>>>>>>>> rule of >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thumb. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 20.01 skrev >>> Ethan >>>>>>>> Li < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensou...@gmail.com>: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Stig, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Do you know what’s the versioning >>> standard we >>>>>>>>>>> have been >>>>>>>>>>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> determine a 2.0.1 release or 2.1.0 >>> release) ? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 12:26 PM, Stig Rohde >>>>>>>>>>> Døssing < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoess...@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev >>> Ethan >>>>>>>>>>> Li < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensou...@gmail.com>: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It’s good idea to do more frequent >>> release. >>>>>>>> I >>>>>>>>>>> can run >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>> next >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I will take a look at both PRs. Other >>> than >>>>>>>>>>> that, I >>>>>>>>>>>>>>>>>>>> think we >>>>>>>>>>>>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> also >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> get >>>>>>>> https://github.com/apache/storm/pull/3093 >>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> https://github.com/apache/storm/pull/3093> >>>>>>>>>>> in the >>>>>>>>>>>>>>>>>> new >>>>>>>>>>>>>>>>>>>>>>>>>> release. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 11:58 AM, Stig >>> Rohde >>>>>>>>>>> Døssing < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoess...@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> With that in mind, I think we should >>> start >>>>>>>>>>> looking at >>>>>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>>>>>>> next >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2.x >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (2.0.1 or 2.1.0?), since it's been a >>> couple >>>>>>>>>>> of months >>>>>>>>>>>>>>>>>>>> since >>>>>>>>>>>>>>>>>>>>>>>>>> 2.0.0 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> released. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The fix list would be >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Govind and Ethan have offered to run >>> the >>>>>>>> next >>>>>>>>>>>>>>>>>> release, >>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>>>>> help >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> validate >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> our release process guidelines. Would >>> one >>>>>>>> of >>>>>>>>>>> you have >>>>>>>>>>>>>>>>>>>> time >>>>>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> work >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release in the near future? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It would be good to take a look at >>>>>>>> currently >>>>>>>>>>> open PRs >>>>>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>>>>>>> decide >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> we >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> feel need to get merged before the >>> next >>>>>>>>>>> release. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would like to see at least >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2990 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> merged >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> https://github.com/apache/storm/pull/2878 >>>>>>>>>>> seems like >>>>>>>>>>>>>>>>>>>> it's >>>>>>>>>>>>>>>>>>>>>>>>>> close >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mergeable too? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >>> >
