Ok, that makes sense. I still don't understand the need for 2.1-SNAPSHOT? If we branch off 2.1.x-branch and then roll master to 2.2.0-SNAPSHOT immediately, we can merge any commits into master and mark them in Jira with fix version 2.2.0. If we then get a bugfix that needs to go in e.g. 2.1.1, we can merge it to master and cherry pick the commit back to 2.1.x-branch, and update the fix version to both 2.2.0 and 2.1.1. This is basically similar to how it worked for the 1.x-branch branches.
Why do we need 2.1-SNAPSHOT? Den man. 19. aug. 2019 kl. 20.03 skrev Ethan Li <ethanopensou...@gmail.com>: > 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? > >
