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 Wed, 14 Aug 2019 17:24:47 GMT
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> wrote:
> 
> Updated 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>:
> 
>> Thank you, Taylor. Will delete them.
>> 
>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <ptgoetz@gmail.com> wrote:
>>> 
>>> Those can be safely deleted.
>>> 
>>> -Taylor
>>> 
>>>> On Aug 13, 2019, at 12:15 PM, Ethan Li <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://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/>
>>>> 
>>>> Just want to be absolutely sure about this. Thanks.
>>>> 
>>>>> On Aug 13, 2019, at 10:56 AM, Ethan Li <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> 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>:
>>>>>> 
>>>>>>> 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>
>>>>>>> wrote:
>>>>>>>> 
>>>>>>>> Oops, sorry that's not right. The license plugin setup was disabled
>> in
>>>>>>>> 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,
>>>>>>>> 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>:
>>>>>>>> 
>>>>>>>>> There's a script that can help you do it in
>>>>>>>>> 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
>>>>>>>>>> :
>>>>>>>>> 
>>>>>>>>>> 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?>
>> 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
>>> 
>>>>>>>>>> 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
>>> 
>>>>>>>>>> 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>
>>>>>>>>>> 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
>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 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
View raw message