The pull request for the fix is 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> 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> > 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>> 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>, >> 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>> 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>> wrote: >>>> >>>> Updated 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>>: >>>> >>>>> Thank you, Taylor. Will delete them. >>>>> >>>>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <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>> >>>>> 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://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/>> >>>>>>> >>>>>>> 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>> >>>>> 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>> 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>>: >>>>>>>>> >>>>>>>>>> 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>> >>>>>>>>>> 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> 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>, >>>>>>>>>>> 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>>: >>>>>>>>>>> >>>>>>>>>>>> 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>. 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> >>>>>>>>>>>>> : >>>>>>>>>>>> >>>>>>>>>>>>> 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?>> >>>>> 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> >>>>>> >>>>>>>>>>>>> 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> >>>>>> >>>>>>>>>>>>> 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>> >>>>>>>>>>>>> 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 >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 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? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>> >> >
