We don’t create 2.1.0 branch. I was thinking (and have been doing) about creating a 2.1.x-branch before doing any thing release related. Then we use 2.1.x-branch to release 2.1.0, and 2.1.1, etc.
When we create a 2.1.x-branch, we move master to 2.2.x-branch. It’s a little different than what we did in the past. But it makes more sense as it follows semantic versioning more strictly. > On Aug 19, 2019, at 12:53 PM, Stig Rohde Døssing <stigdoess...@gmail.com> > wrote: > > I would be fine with just freezing (non-critical) merges during the > release process. These mails are public, so it's easy for anyone to see > whether a release is in progress. > > If we want to do merges while releases are going on, I think your proposal > of using a release branch is fine. I'm not sure I understand why we need > the 2.1-SNAPSHOT version though? > > Let's say we create release branch 2.1.0-branch from master. We roll the > master version to 2.1.1-SNAPSHOT (for example) after the 2.1.0 branch is > created. We then get a bug fix that should go in 2.1.0. In this case we > should merge it to 2.1.0-branch, then merge 2.1.0-branch to master. In Jira > we mark it as going in 2.1.0. > > We then get a PR that shouldn't be included in 2.1.0. We just merge it to > master, and mark it as 2.1.1 in Jira. > > Finally once 2.1.0 is released, we merge 2.1.0-branch into master and > delete 2.1.0-branch. > > Why is there a need to 2.1-SNAPSHOT? > > Den man. 19. aug. 2019 kl. 18.15 skrev Ethan Li <ethanopensou...@gmail.com > <mailto:ethanopensou...@gmail.com>>: > >> Many issues came up while I was preparing for 2.1.0 release. Freezing >> merge until the release is done is not practical. So I am proposing: >> >> 1. Once we decide to make a release, we create a new branch based on >> master and start release process. >> 2. During the new process, master is still open for backwards >> compatibility commits, including new features, bu g fixes, etc. >> 3. Only bug fixes will be merged to the new branch and we need to restart >> the release process to include the bug fixes. >> 4. To avoid too much confusion on pom versions when we merge new commits >> during the release process, we should use less concrete version. For >> example, in 2.1.x-branch, the pom version should be 2.1-SNAPSHOT, instead >> of 2.1.0-SNAPSHOT. >> >> For example, >> >> Let’s say we have a new branch 2.1.x-branch, the pom version is >> 2.1.0-SNAPSHOT. We start the release process and after running the mvn >> release:prepare -Pxxx command, the pom version changes to 2.1.1-SNAPSHOT, >> and before that a git tag v2.1.0 is created. Now if there is a bug fix we >> have to merge in, so we merge in and it’s actually merged in to >> 2.1.1-SNAPSHOT at this point if we don’t manually revert the pom version, >> which can be confusing. We can avoid this problem by just using >> 2.1-SNAPSHOT as the pom version. So it doesn’t have to change. >> >> Please let me know if there is any potential risk for doing this. >> >> Thanks >> Ethan >> >>> On Aug 19, 2019, at 10:25 AM, Ethan Li <ethanopensou...@gmail.com> >> wrote: >>> >>> The pull request for the fix is >> https://github.com/apache/storm/pull/3106 < >> https://github.com/apache/storm/pull/3106 >> <https://github.com/apache/storm/pull/3106>> >>> >>>> On Aug 19, 2019, at 10:15 AM, Ethan Li <ethanopensou...@gmail.com >>>> <mailto:ethanopensou...@gmail.com> >> <mailto:ethanopensou...@gmail.com <mailto:ethanopensou...@gmail.com>>> wrote: >>>> >>>> So I was preparing for a new release candidate i.e. rc3. I can build it >> from source without any problem. Then I set up a standalone cluster and >> submitted a WordCountTopology. The workers kept restarting because of >>>> >>>> >>>> 2019-08-19 15:09:49.635 o.a.s.t.ShellBolt Thread-30 [ERROR] Halting >> process: ShellBolt died. Command: [python, splitsentence.py], ProcessInfo >> pid:3756, name:split exitCode:-1, errorString: >>>> java.lang.IllegalArgumentException: command sync is not supported >>>> at >> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366) >> [storm-client-2.1.0.jar:2.1.0] >>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181] >>>> 2019-08-19 15:09:49.635 o.a.s.e.e.ReportError Thread-30 [ERROR] Error >>>> java.lang.IllegalArgumentException: command sync is not supported >>>> at >> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366) >> [storm-client-2.1.0.jar:2.1.0] >>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181] >>>> 2019-08-19 15:09:49.636 o.a.s.t.ShellBolt Thread-28 [ERROR] Halting >> process: ShellBolt died. Command: [python, splitsentence.py], ProcessInfo >> pid:3755, name:split exitCode:-1, errorString: >>>> java.lang.IllegalArgumentException: command sync is not supported >>>> at >> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366) >> [storm-client-2.1.0.jar:2.1.0] >>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181] >>>> 2019-08-19 15:09:49.637 o.a.s.e.e.ReportError Thread-28 [ERROR] Error >>>> java.lang.IllegalArgumentException: command sync is not supported >>>> at >> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366) >> [storm-client-2.1.0.jar:2.1.0] >>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181] >>>> >>>> >>>> >>>> >> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 >> >> <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367> >> < >> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 >> >> <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367>> >> I believe we shouldn’t throw exceptions here. >>>> >>>> Will make a pull request to fix it. >>>> >>>> >>>> >>>>> On Aug 14, 2019, at 11:11 PM, Ethan Li <ethanopensou...@gmail.com >>>>> <mailto:ethanopensou...@gmail.com> >> <mailto:ethanopensou...@gmail.com <mailto:ethanopensou...@gmail.com>>> wrote: >>>>> >>>>> 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> >> < >> 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 >>>>>> <mailto:ethanopensou...@gmail.com> >> <mailto:ethanopensou...@gmail.com <mailto: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 <mailto:stigdoess...@gmail.com> >> <mailto:stigdoess...@gmail.com <mailto:stigdoess...@gmail.com>>> wrote: >>>>>>> >>>>>>> Updated https://github.com/apache/storm/pull/3053 >>>>>>> <https://github.com/apache/storm/pull/3053> < >> https://github.com/apache/storm/pull/3053 >> <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 <mailto:ethanopensou...@gmail.com> >> <mailto:ethanopensou...@gmail.com <mailto:ethanopensou...@gmail.com>>>: >>>>>>> >>>>>>>> Thank you, Taylor. Will delete them. >>>>>>>> >>>>>>>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <ptgo...@gmail.com >>>>>>>>> <mailto:ptgo...@gmail.com> >> <mailto:ptgo...@gmail.com <mailto:ptgo...@gmail.com>>> wrote: >>>>>>>>> >>>>>>>>> Those can be safely deleted. >>>>>>>>> >>>>>>>>> -Taylor >>>>>>>>> >>>>>>>>>> On Aug 13, 2019, at 12:15 PM, Ethan Li <ethanopensou...@gmail.com >>>>>>>>>> <mailto:ethanopensou...@gmail.com> >> <mailto:ethanopensou...@gmail.com <mailto: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://dist.apache.org/repos/dist/dev/storm >> <https://dist.apache.org/repos/dist/dev/storm>> < >>>>>>>> https://dist.apache.org/repos/dist/dev/storm >>>>>>>> <https://dist.apache.org/repos/dist/dev/storm> < >> 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> >> < >> 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> >>> >>>>>>>> < >>>>>>>> >> 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> >> < >> 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/> < >> https://dist.apache.org/repos/dist/dev/storm/ >> <https://dist.apache.org/repos/dist/dev/storm/>> < >>>>>>>> https://dist.apache.org/repos/dist/dev/storm/ >>>>>>>> <https://dist.apache.org/repos/dist/dev/storm/> < >> 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 <mailto:ethanopensou...@gmail.com> >> <mailto:ethanopensou...@gmail.com <mailto: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 <mailto:stigdoess...@gmail.com> >>>>>>>> <mailto:stigdoess...@gmail.com <mailto: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 <mailto:ethanopensou...@gmail.com> >>>>>>>> <mailto:ethanopensou...@gmail.com <mailto: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 <mailto:stigdoess...@gmail.com> >>>>>>>> <mailto:stigdoess...@gmail.com <mailto:stigdoess...@gmail.com>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Oops, sorry that's not right. The license plugin setup was >> disabled >>>>>>>> in >>>>>>>>>>>>>> https://github.com/apache/storm/pull/3031 >>>>>>>>>>>>>> <https://github.com/apache/storm/pull/3031> < >> https://github.com/apache/storm/pull/3031 >> <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 >>>>>>>> <https://github.com/apache/storm/pull/3053> < >> https://github.com/apache/storm/pull/3053 >> <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 <mailto:stigdoess...@gmail.com> >>>>>>>>>>>>>> <mailto:stigdoess...@gmail.com <mailto:stigdoess...@gmail.com>>>: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> There's a script that can help you do it in >>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3053 >>>>>>>>>>>>>>> <https://github.com/apache/storm/pull/3053> < >> https://github.com/apache/storm/pull/3053 >> <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 <mailto:ethanopensou...@gmail.com> >>>>>>>>>>>>> <mailto:ethanopensou...@gmail.com >>>>>>>>>>>>> <mailto: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?> < >> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? >> <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>> >>>>>>>> < >>>>>>>>>>>>>>>> >> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? >> <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> < >> 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 <mailto:ethanopensou...@gmail.com> >> <mailto:ethanopensou...@gmail.com <mailto: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 <mailto:ptgo...@gmail.com> <mailto:ptgo...@gmail.com >> <mailto: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 <mailto:ethanopensou...@gmail.com> >>>>>>>> <mailto:ethanopensou...@gmail.com <mailto: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> >> < >> 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> >>> >>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>> >> 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?
