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 <stigdoessing@gmail.com> 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 <ethanopensource@gmail.com <mailto:ethanopensource@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 <stigdoessing@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 <
>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@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 <ethanopensource@gmail.com <mailto:ethanopensource@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 <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 <ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>
>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>
>>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@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>
>>>
>>>> <
>>>>
>> 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 <ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>
>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>
>>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@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>
>>>
>>>> <
>>>>
>> 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 <ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>
>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>
>>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@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 <
>>>> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>> <mailto:
>> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@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>> <
>>>> 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 <
>>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>> <mailto:
>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>>>:
>>>>>>>>>
>>>>>>>>>> Thank you, Taylor. Will delete them.
>>>>>>>>>>
>>>>>>>>>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <ptgoetz@gmail.com <mailto:ptgoetz@gmail.com>
>> <mailto:ptgoetz@gmail.com <mailto:ptgoetz@gmail.com>>
>>>> <mailto:ptgoetz@gmail.com <mailto:ptgoetz@gmail.com> <mailto:ptgoetz@gmail.com <mailto:ptgoetz@gmail.com>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Those can be safely deleted.
>>>>>>>>>>>
>>>>>>>>>>> -Taylor
>>>>>>>>>>>
>>>>>>>>>>>> On Aug 13, 2019, at 12:15 PM, Ethan Li <
>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>
>>>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@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://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 <
>>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>> <mailto:
>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@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 <
>>>>>>>>>> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>> <mailto:
>> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@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 <
>>>>>>>>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>
>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@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 <
>>>>>>>>>> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>> <mailto:
>> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@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>> <
>>>> 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 <
>>>>>>>>>>>>>>>> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>>
>> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@gmail.com> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@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>> <
>>>> 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 <
>>>>>>>>>>>>>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>
>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@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?>>>
>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>
>>>> 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 <
>>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>> <mailto:
>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@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 <
>>>> ptgoetz@gmail.com <mailto:ptgoetz@gmail.com> <mailto:ptgoetz@gmail.com <mailto:ptgoetz@gmail.com>> <mailto:ptgoetz@gmail.com <mailto:ptgoetz@gmail.com>
>> <mailto:ptgoetz@gmail.com <mailto:ptgoetz@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 <
>>>>>>>>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>
>> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@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
>>>
>>>>>
>>>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>
>>>>
>> 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 <
>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>> ptgoetz@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 <
>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>>>> dagit@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 <
>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>>>> dagit@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 <
>>>>>>>>>>>>>>>>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>>>>>>>>>>>>>> <mailto:dagit@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 <
>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde
>>>> Døssing
>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W.
>> Call
>>>> <
>>>>>>>>>>>>>>>>>> bcall@apache.org
>>>>>>>>>>>>>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bcall@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev
>>>> Ethan
>>>>>>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>> hmclouro@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig
>>>> Rohde
>>>>>>>>>>>>>>> Døssing <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16
>>>> skrev
>>>>>>>>>> Ethan
>>>>>>>>>>>>>>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
|