storm-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Li <ethanopensou...@gmail.com>
Subject Re: [DISCUSS] Next 2.x release
Date Mon, 19 Aug 2019 18:03:17 GMT
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>>:
> 
>> 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>
>> wrote:
>>> 
>>> The pull request for the fix is
>> https://github.com/apache/storm/pull/3106 <
>> https://github.com/apache/storm/pull/3106 <https://github.com/apache/storm/pull/3106>>
>>> 
>>>> On Aug 19, 2019, at 10:15 AM, Ethan Li <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>>
>> 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>>> wrote:
>>>>> 
>>>>> Hi Taylor,
>>>>> 
>>>>> Mostly I was able to follow the doc
>> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>>,
>> except:
>>>>> 
>>>>> For Step 1,  I used the following command as suggested.
>>>>> mvn release:prepare -P dist,rat,externals,examples
>>>>> mvn release:perform -P dist,rat,externals,examples
>>>>> 
>>>>> 
>>>>> For Step3,  I had to run "git checkout tags/v2.1.0 -b v2.1.0” so that
>> I can run “mvn package” for storm-dist/binary and storm-dist/source based
>> on v2.1.0. Otherwise if I run “mvn package” on 2.1.x-branch, it will fail
>> because the pom version is “2.1.x-SNAPSHOT”.
>>>>> 
>>>>> Then I find packages in storm-dist/binary/final-package/target and
>> storm-dist/source/target, sign them, generate checksum and copy them to svn.
>>>>> 
>>>>> I think there are something I should do. But please let me know if I
>> was doing something wrong.  I will  also update the doc after the release
>> is complete. Thank you very much!
>>>>> 
>>>>> Ethan
>>>>> 
>>>>> 
>>>>>> On Aug 14, 2019, at 12:24 PM, Ethan Li <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>>> wrote:
>>>>>>> 
>>>>>>> Updated https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>> so we don't have
>>>>>>> org.apache.storm artifacts in the DEPENDENCY-LICENSES file. It's
>> ready for
>>>>>>> review if someone wants to look at it.
>>>>>>> 
>>>>>>> Den tir. 13. aug. 2019 kl. 18.21 skrev Ethan Li <
>> 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>>> 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>>>
>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Do we need/want to clean up the release candidate from
>>>>>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>> <
>>>>>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>>> ?
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>> 
>>>>>>>> <
>>>>>>>> 
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>> 
>>>>>>>> says we do. But we have a lot of rc in
>>>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>> <
>>>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>>>
>>>>>>>>>> 
>>>>>>>>>> Just want to be absolutely sure about this. Thanks.
>>>>>>>>>> 
>>>>>>>>>>> On Aug 13, 2019, at 10:56 AM, Ethan Li <
>> 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>>> 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>>>:
>>>>>>>>>>>> 
>>>>>>>>>>>>> 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>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Oops, sorry that's not right. The license plugin setup was
>> disabled
>>>>>>>> in
>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031> <
>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031>> due to a bug in the
>>>>>>>> license
>>>>>>>>>>>>>> plugin. It is added back in
>>>>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>>,
>>>>>>>>>>>>>> where we've upgraded the plugin. Until that PR goes in, we
>> can't
>>>>>>>> easily
>>>>>>>>>>>>>> regenerate DEPENDENCY-LICENSES.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Den tir. 13. aug. 2019 kl. 17.15 skrev Stig Rohde Døssing <
>>>>>>>>>>>>>> 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>>. 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>>
>>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Hi Stig,
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> How do we update
>>>>>>>>>>>>>>>> 
>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>>
>>>>>>>> <
>>>>>>>>>>>>>>>> 
>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>>>
>>>>>>>> Is
>>>>>>>>>>>>>>>> there a command I can use? Or I just replace strings
>> manually?
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>>>>> Ethan
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Aug 12, 2019, at 3:54 PM, Ethan Li <
>> 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>>
>>>>>>>>> 
>>>>>>>>>>>>>>>> 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>>>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> I have one more question before I can start a vote.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> In previous [VOTE] thread, Taylor always has this:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> The release artifacts are signed with the following key:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>> 
>> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd <https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd>
>> <
>> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd <https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd>
>>> 
>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>> 
>> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
>> <
>> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Does anyone know where to find the updated KEYs file?
>> Should I
>>>>>>>> just
>>>>>>>>>>>>>>>> use https://www.apache.org/dist/storm/KEYS <
>>>>>>>>>>>>>>>> https://www.apache.org/dist/storm/KEYS> ?
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Thanks very much
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On Aug 12, 2019, at 9:44 AM, Ethan Li <
>>>>>>>> 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?


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message