You are right. But I was talking about the pom version. So if we have 2.1.x-branch and the pom version is 2.1.0-SNAPSHOT. If we start release process here, i.e. run “mvn release:prepare”, it will create and push two commits automatically.
First commit: change pom version to 2.1.0; and create a v2.1.0 git tag. Second commit: change pom version to 2.1.1-SNAPSHOT. So now in 2.1.x-branch, the pom version is 2.1.1-SNAPSHOT. Now if we need to merge something in (2.1.0 is not released yet), we merge it to 2.1.x-branch. But the current pom version is 2.1.1-SNAPSHOT, which should really be 2.1.0-SNAPSHOT, because this commit goes into 2.1.0 version. To fix this, we need to revert last two commits before we merge the new commit. If we use 2.1-SNAPSHOT, we don’t need to revert. With that being said, I am fine with reverting if needed. It’s probably safe to not change the convention. > On Aug 19, 2019, at 1:24 PM, Stig Rohde Døssing <[email protected]> > wrote: > > 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 <[email protected] > <mailto:[email protected]>>: > >> 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 <[email protected]> >> 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 < >> [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>: >>> >>>> 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 <[email protected] >>>>> <mailto:[email protected]>> >>>> 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 >>>> <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 <[email protected] >>>>>> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >>>> <mailto:[email protected] <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>>>> >> 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> >>> >>>> < >>>> >> 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 <[email protected] >>>>>>> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >>>> <mailto:[email protected] <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>>>> >> 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> >>> >>>> < >>>> >> 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 <[email protected] >>>>>>>> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >>>> <mailto:[email protected] <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>>>> >> 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 < >>>> [email protected] <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>> <mailto: >> [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>> 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>> < >>>> 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 < >>>> [email protected] <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>> >>>> <mailto: >> [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>>: >>>>>>>>> >>>>>>>>>> Thank you, Taylor. Will delete them. >>>>>>>>>> >>>>>>>>>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <[email protected] >>>>>>>>>>> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >>>> <mailto:[email protected] <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> Those can be safely deleted. >>>>>>>>>>> >>>>>>>>>>> -Taylor >>>>>>>>>>> >>>>>>>>>>>> On Aug 13, 2019, at 12:15 PM, Ethan Li < >> [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>> >>>> <mailto:[email protected] <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>>>> >>>>>>>>>> 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://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> >>> >>>>> >>>>>>>>>> < >>>>>>>>>> >>>> >> 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/>>> < >>>>>>>>>> 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 < >>>> [email protected] <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>> >>>> <mailto: >> [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>> >>>>>>>>>> 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 < >>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>> <mailto:[email protected] <mailto:[email protected]>> >>>>>>>>>> <mailto: >> [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>> 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 < >>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>> <mailto:[email protected] <mailto:[email protected]>> >> <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>>: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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 < >>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>> <mailto:[email protected] <mailto:[email protected]>> >>>>>>>>>> <mailto: >> [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>> >>>>>>>>>>>>>>> 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>> < >>>> 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>> < >>>> 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 < >>>>>>>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>>>>>>> <mailto:[email protected] <mailto:[email protected]>> >> <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>>: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 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>> < >>>> 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 < >>>>>>>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>>>>>>> <mailto:[email protected] >>>>>>>>>>>>>>> <mailto:[email protected]>> >> <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> >>>>>>>>>>>>>>>>>> : >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 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?>>> >>>>>>>>>> < >>>>>>>>>>>>>>>>>> >>>> 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 < >>>> [email protected] <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>> >>>> <mailto: >> [email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> >>>>>>>>>>> >>>>>>>>>>>>>>>>>> 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 < >>>> [email protected] <mailto:[email protected]> <mailto:[email protected] >>>> <mailto:[email protected]>> <mailto:[email protected] >>>> <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>> >>>>>>>>>>> >>>>>>>>>>>>>>>>>> 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 < >>>>>>>>>> [email protected] <mailto:[email protected]> >>>>>>>>>> <mailto:[email protected] <mailto:[email protected]>> >> <mailto:[email protected] <mailto:[email protected]> >> <mailto:[email protected] <mailto:[email protected]>>>> >>>>>>>>>>>>>>>>>> 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 >>> >>>>> >>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> >>>> >> 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 < >>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>> 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 < >>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>>>>> [email protected]>: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>>>>>>>>>>>> [email protected]>: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>>>>>>>>> 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 < >>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>> <mailto: >>>>>>>>>>>>>>>>>>>>>>>>>>> [email protected]>> 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 < >>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>> <mailto: >>>>>>>>>>>>>>>>>>>>>>>>>>> [email protected]>> 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 < >>>>>>>>>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>>>>>>>>>>> <mailto:[email protected]>>: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde >>>> Døssing >>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [email protected]> 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 < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [email protected]>: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. >> Call >>>> < >>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>>>>>>>>>>> <mailto: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [email protected]>> (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 < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev >>>> Ethan >>>>>>>>>> Li < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [email protected]>: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>>>>>>>>>>>> [email protected] >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig >>>> Rohde >>>>>>>>>>>>>>> Døssing < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [email protected]>: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 >>>> skrev >>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>> Li < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [email protected]>: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> [email protected]> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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?
