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 <ethanopensou...@gmail.com> wrote: > > That sounds better. It will be easier for release. Thank you for looking into > this. > >> On Aug 13, 2019, at 10:54 AM, Stig Rohde Døssing <stigdoess...@gmail.com> >> wrote: >> >> Makes sense. I'll take a look at it. Ideally I'd want the license files to >> just not include org.apache.storm artifacts. I don't think we need to tell >> people that the project depends on itself. >> >> If we can exclude these artifacts from the lists, I don't think the release >> plugin needs to update these files. >> >> Den tir. 13. aug. 2019 kl. 17.36 skrev Ethan Li <ethanopensou...@gmail.com>: >> >>> Thanks Stig. >>> >>> In this case, we probably should abort release process and get this merged >>> into master first. Also we need to make sure it works with “mvn >>> release:prepare” since “ mvn release:prepare” will automatically push two >>> commits. For example, >>> >>> (1) [maven-release-plugin] prepare release v2.1.0: this commit changes >>> the pom version to 2.1.0, push the commit, and then create a git tag v2.1.0. >>> >>> (2) [maven-release-plugin] prepare for next development iteration: this >>> commit changes the pom version to 2.1.1-SNAPSHOT. >>> >>> >>> We need DEPENDENCY-LICENSES to be updated on every step. >>> >>> >>> >>>> On Aug 13, 2019, at 10:24 AM, Stig Rohde Døssing <stigdoess...@gmail.com> >>> 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 < >>>> stigdoess...@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 < >>> ethanopensou...@gmail.com >>>>>> : >>>>> >>>>>> Hi Stig, >>>>>> >>>>>> How do we update >>>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? < >>>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> Is >>>>>> there a command I can use? Or I just replace strings manually? >>>>>> >>>>>> Thanks >>>>>> Ethan >>>>>> >>>>>>> On Aug 12, 2019, at 3:54 PM, Ethan Li <ethanopensou...@gmail.com> >>>>>> wrote: >>>>>>> >>>>>>> Yes my public keys in that file. Thanks! Ready to set up a vote. >>>>>>> >>>>>>>> On Aug 12, 2019, at 3:52 PM, P. Taylor Goetz <ptgo...@gmail.com> >>>>>> wrote: >>>>>>>> >>>>>>>> Yes. Is you public key in that file? If not you should add it. >>>>>>>> >>>>>>>> -Taylor >>>>>>>> >>>>>>>>> On Aug 12, 2019, at 4:15 PM, Ethan Li <ethanopensou...@gmail.com> >>>>>> 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 <ethanopensou...@gmail.com> >>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Thanks Stig and Taylor! It worked. I will continue the process now >>>>>> and update the documentation later. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Aug 12, 2019, at 9:40 AM, P. Taylor Goetz <ptgo...@gmail.com> >>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> For the 2.x version lines, there are a bunch of profiles you need >>>>>> to enable. This is what I use when preparing a release: >>>>>>>>>>> >>>>>>>>>>> -P dist,include-shaded-deps,rat,externals,examples >>>>>>>>>>> >>>>>>>>>>> -Taylor >>>>>>>>>>> >>>>>>>>>>>> On Aug 12, 2019, at 9:27 AM, Stig Rohde Døssing < >>>>>> stigdoess...@gmail.com> wrote: >>>>>>>>>>>> >>>>>>>>>>>> Try enabling the "dist" profile by adding "-P >>>>>> dist,externals,examples" to >>>>>>>>>>>> the command you're running. See >>>>>>>>>>>> https://github.com/apache/storm/blob/master/pom.xml#L518. Unless >>>>>> you enable >>>>>>>>>>>> that profile, the storm-dist modules aren't in the reactor. >>>>>>>>>>>> >>>>>>>>>>>> Den man. 12. aug. 2019 kl. 15.15 skrev Ethan Li < >>>>>> ethanopensou...@gmail.com>: >>>>>>>>>>>> >>>>>>>>>>>>> Just in case if anyone happens to know the answer: >>>>>>>>>>>>> >>>>>>>>>>>>> I created a branch >>>>>> https://github.com/apache/storm/tree/2.1.x-branch < >>>>>>>>>>>>> https://github.com/apache/storm/tree/2.1.x-branch> and ran >>>>>> “mvn:prepare” >>>>>>>>>>>>> and “mvn:perform”. It created two commits and created a v2.1.0 >>>>>> git tag. But >>>>>>>>>>>>> I realized that the pom version under storm-dist was not updated >>>>>> and it’s >>>>>>>>>>>>> still 2.0.1-SNAPSHOT. I checked the commits in other tags like >>>>>>>>>>>>> https://github.com/apache/storm/commits/v2.0.0 < >>>>>>>>>>>>> https://github.com/apache/storm/commits/v2.0.0> and it looks >>> like >>>>>>>>>>>>> storm-dist got updated within the “mvn:prepare” step. How do I >>>>>> get >>>>>>>>>>>>> storm-dist pom version updated with “mv:prepare”? >>>>>>>>>>>>> >>>>>>>>>>>>> I am currently blocked on this. Any help will be appreciated. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Ethan >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On Aug 12, 2019, at 2:38 AM, Stig Rohde Døssing < >>>>>> stigdoess...@gmail.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sounds good Ethan. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Derek, I also think being clear about how long we expect to >>>>>> support a >>>>>>>>>>>>>> release line is a good idea. Maybe we should do a separate >>>>>> discuss thread >>>>>>>>>>>>>> on this, or if you already have a good idea for what the policy >>>>>> should >>>>>>>>>>>>> look >>>>>>>>>>>>>> like you could put it up as a PR for either the Downloads page >>>>>> or a new >>>>>>>>>>>>>> page on the Storm site? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Den søn. 11. aug. 2019 kl. 08.37 skrev Ethan Li < >>>>>>>>>>>>> ethanopensou...@gmail.com>: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I am doing the release following >>>>>>>>>>>>>>> https://github.com/apache/storm/blob/master/RELEASING.md < >>>>>>>>>>>>>>> https://github.com/apache/storm/blob/master/RELEASING.md> . I >>>>>> made some >>>>>>>>>>>>>>> progress but I have some questions so I just sent an email to >>>>>> Taylor. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please don’t merge anything to master or 2.1.x-branch for now. >>>>>> Thanks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best, >>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Aug 9, 2019, at 4:45 PM, Ethan Li < >>>>>> ethanopensou...@gmail.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Currently we have two outstanding PRs that we wanted to >>>>>> include in the >>>>>>>>>>>>>>> new release: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3096 < >>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3096> (Travis has some >>>>>> issues >>>>>>>>>>>>>>> connecting to repository.apache.org < >>>>>> http://repository.apache.org/> >>>>>>>>>>>>>>> recently. Travis build fails consistently) >>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878 < >>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878> (Some comments are >>>>>> to be >>>>>>>>>>>>>>> addressed but Author hasn’t responded yet.) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It’s not absolutely necessary to include them in this new >>>>>> release so I >>>>>>>>>>>>>>> think I should move forward with the release process. These >>> two >>>>>> and >>>>>>>>>>>>> other >>>>>>>>>>>>>>> PRs can be included in the next release. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> For the release, I will create a new branch 2.1.x-branch >>> based >>>>>> on >>>>>>>>>>>>>>> current master branch, and release 2.1.0 from there. I will >>>>>> then move >>>>>>>>>>>>>>> master to 2.2.0-SNAPSHOT. Please let me know if there is any >>>>>>>>>>>>> objections. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Aug 9, 2019, at 2:53 PM, Derek Dagit <da...@apache.org >>>>>> <mailto: >>>>>>>>>>>>>>> da...@apache.org>> wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> We might not able to say how long we want to support a >>>>>> specific >>>>>>>>>>>>>>>>>> release line but I would love to see a clear release policy >>>>>> being >>>>>>>>>>>>>>>>>> made. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> That makes sense. It seems better for us not to choose a >>>>>> specific >>>>>>>>>>>>>>>>> calendar date or duration of time. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> - We do not want too many release lines supported >>>>>> concurrently. >>>>>>>>>>>>>>>>> - We want devs and users to know what to expect. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Derek >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On Fri, Aug 09, 2019 at 10:32:59AM -0500, Ethan Li wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Derek, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I think it’s a good idea to be more clear on the versioning >>>>>> and >>>>>>>>>>>>>>> release process so users and developers know what to expect. >>> We >>>>>> might >>>>>>>>>>>>> not >>>>>>>>>>>>>>> able to say how long we want to support a specific release >>> line >>>>>> but I >>>>>>>>>>>>> would >>>>>>>>>>>>>>> love to see a clear release policy being made. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Aug 9, 2019, at 8:53 AM, Derek Dagit <da...@apache.org >>>>>> <mailto: >>>>>>>>>>>>>>> da...@apache.org>> wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On Fri, Aug 09, 2019 at 02:35:57PM +0200, Stig Rohde >>>>>> Døssing wrote: >>>>>>>>>>>>>>>>>>>> Where on the Traffic Server page do they list how long >>>>>> their >>>>>>>>>>>>> release >>>>>>>>>>>>>>>>>>>> trains survive? I only see dates of release, not how long >>>>>> e.g. 7.x >>>>>>>>>>>>> is >>>>>>>>>>>>>>>>>>>> supposed to receive support. Derek, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> This is a better link: >>>>>>>>>>>>>>> >>>>>> https://cwiki.apache.org/confluence/display/TS/Release+Management < >>>>>>>>>>>>>>> >>>>>> https://cwiki.apache.org/confluence/display/TS/Release+Management> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> This example, where "RM" means "Release Manager": >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 1. We promise to make 1 major release / year, but the RM >>>>>> and >>>>>>>>>>>>>>> community >>>>>>>>>>>>>>>>>>>> can of course make more as necessary >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 2. We only make releases off the LTS branches, which are >>>>>> cut once a >>>>>>>>>>>>>>>>>>>> year off master >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 3. Master is always open, for any type of change >>> (including >>>>>>>>>>>>>>>>>>>> incompatible changes). But don't break compatibility just >>>>>> for fun! >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 4. Master is always stable, i.e. commits should be >>>>>> properly tested >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>> reviewed before committed to master. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 5. All releases are stable releases, following strict >>>>>> Semantic >>>>>>>>>>>>>>>>>>>> Versioning. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 6. Minor releases are made at the discretion at the >>>>>> discretion of >>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>> community and the RM. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 7. Minor releases can include new (small / safe) >>> features, >>>>>> but must >>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>>> compatible within the LTS major version. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 8. The LTS cycle, 2 years + 6 months Sunset, does not >>>>>> reset when we >>>>>>>>>>>>>>>>>>>> make a minor release. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Now, I am not proposing we do exactly this. The goal would >>>>>> be to set >>>>>>>>>>>>>>>>>>> expectations among developers and the community, and here >>>>>> is one >>>>>>>>>>>>>>>>>>> concrete example of how it could be done. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> If we're going to promise that a release line survives >>> for >>>>>> a given >>>>>>>>>>>>>>>>>>>> amount of time, I think we should do it at the major >>>>>> version level >>>>>>>>>>>>>>>>>>>> only >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Yeah, that sounds reasonable to me. If we choose to commit >>>>>> to >>>>>>>>>>>>>>> something >>>>>>>>>>>>>>>>>>> like the above, we should base the decision in part on >>> what >>>>>> kind of >>>>>>>>>>>>>>>>>>> resources we have so that we do not over-commit. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Den fre. 9. aug. 2019 kl. 00.15 skrev Derek Dagit < >>>>>>>>>>>>> da...@apache.org >>>>>>>>>>>>>>> <mailto:da...@apache.org>>: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> What do we think about defining Long-Term Support >>>>>> branches with a >>>>>>>>>>>>>>> fixed >>>>>>>>>>>>>>>>>>>>> period of support? >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> For example, we could say 2.0.x is an LTS release line >>>>>> with >>>>>>>>>>>>> support >>>>>>>>>>>>>>>>>>>>> ending no earlier than a certain calendar date. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> The date could be extended, and it might ultimately be >>>>>> governed by >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> timing of the subsequent release (e.g., 2.1.x or 3.0.x). >>>>>> Keeping >>>>>>>>>>>>>>> things >>>>>>>>>>>>>>>>>>>>> clear would imply semantic versioning as mentioned >>> earlier >>>>>>>>>>>>>>>>>>>>> (https://semver.org/ <https://semver.org/>). >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Apache Traffic Server does something like this, to name >>>>>> one >>>>>>>>>>>>> project: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> https://trafficserver.apache.org/downloads < >>>>>>>>>>>>>>> https://trafficserver.apache.org/downloads> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Having a regular cadence of releases might also help >>> make >>>>>> the >>>>>>>>>>>>>>> process >>>>>>>>>>>>>>>>>>>>> easier and help set expectations for users and devs. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> Derek >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Thu, Aug 08, 2019 at 02:50:07PM -0500, Ethan Li >>> wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Currently we don’t have a 2.0.x-branch and master is >>>>>> actually >>>>>>>>>>>>>>>>>>>>> “2.0.1-SNAPSHOT”. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> So if we do a 2.1.0 release, we will create a >>>>>> 2.1.x-branch >>>>>>>>>>>>> based >>>>>>>>>>>>>>> on >>>>>>>>>>>>>>>>>>>>> current master, release from there. And we change master >>>>>> to >>>>>>>>>>>>>>>>>>>>> “2.2.0-SNAPSHOT”. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> But we will have one problem: we will lose 2.0.x >>> release >>>>>> line. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> There are two things I can do: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 1) create a 2.0.x-branch based on v2.0.0 tag. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> 2) ignore it. If there is an issue with 2.0.x release, >>>>>> ask users >>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>> upgrade to 2.1.0. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I prefer 1) but not sure if it’s the right way to make >>>>>> things >>>>>>>>>>>>>>> right. Or >>>>>>>>>>>>>>>>>>>>> please let me know if I misunderstood something and it’s >>>>>> not an >>>>>>>>>>>>>>> issue. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Btw, I am seeing the same issue with 1.x-branch. We >>>>>> shouldn’t >>>>>>>>>>>>> have >>>>>>>>>>>>>>>>>>>>> 1.x-branch. Instead, we should have 1.2.x-branch. But >>>>>> this is not >>>>>>>>>>>>> a >>>>>>>>>>>>>>> problem >>>>>>>>>>>>>>>>>>>>> since we will not release 1.3.x. >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:43 AM, Ethan Li < >>>>>>>>>>>>> ethanopensou...@gmail.com> >>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Yes thanks. >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing < >>>>>>>>>>>>>>>>>>>>> stigdoess...@gmail.com> wrote: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Sounds great. Remember to add your key to >>>>>>>>>>>>>>>>>>>>>>>> >>> https://dist.apache.org/repos/dist/release/storm/KEYS, >>>>>> you >>>>>>>>>>>>>>> should be >>>>>>>>>>>>>>>>>>>>> able >>>>>>>>>>>>>>>>>>>>>>>> to update it with an SVN client. See also >>>>>>>>>>>>>>>>>>>>>>>> https://www.apache.org/dev/openpgp.html#update. >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Den ons. 7. aug. 2019 kl. 15.05 skrev Ethan Li < >>>>>>>>>>>>>>>>>>>>> ethanopensou...@gmail.com>: >>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call < >>>>>> bc...@apache.org >>>>>>>>>>>>>>> <mailto: >>>>>>>>>>>>>>>>>>>>>>>>> bc...@apache.org>> (Thanks to him). >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> My pgp key: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> >>> http://pgp.surfnet.nl/pks/lookup?op=vindex&fingerprint=on&search=0xA4A672F11B5050C8 >>>>>>>>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> >>> http://pgp.surfnet.nl/pks/lookup?op=vindex&fingerprint=on&search=0xA4A672F11B5050C8 >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> My understanding is that I am good to do release >>> with >>>>>> this key >>>>>>>>>>>>>>> now. >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Here is a list of PRs that we might want to include >>>>>> in the new >>>>>>>>>>>>>>>>>>>>> release: >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3098 < >>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3098> >>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3096 < >>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3096> >>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878 < >>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Please review if you get a chance. Thanks >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 1, 2019, at 4:19 AM, Stig Rohde Døssing < >>>>>>>>>>>>>>>>>>>>> stigdoess...@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense. >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li < >>>>>>>>>>>>>>>>>>>>>>>>> ethanopensou...@gmail.com>: >>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> It’s a good point. I will start a discussion >>> thread >>>>>> for it. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> For the new release, I went through the list: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> >>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1 >>>>>>>>>>>>>>>>>>>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> >>> https://issues.apache.org/jira/issues/?jql=project%20=%20STORM%20AND%20fixVersion%20=%202.0.1 >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> We introduced some new functionalities, including >>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-2720 >>> < >>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-2720> >>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3412 >>> < >>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3412> >>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3411 >>> < >>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3411> >>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3442 >>> < >>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3442> >>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3396 >>> < >>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3396> >>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3392 >>> < >>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3392> >>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3395 >>> < >>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/STORM-3395> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> So I think we should release 2.1.0 rather than >>>>>> 2.0.1. >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> There are a few pull requests we may want to >>> review >>>>>> before >>>>>>>>>>>>>>> the next >>>>>>>>>>>>>>>>>>>>>>>>>>> release: >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3094 < >>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3094> >>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2990 < >>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2990> >>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878 < >>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks >>>>>>>>>>>>>>>>>>>>>>>>>>> Ethan >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 29, 2019, at 10:11 AM, Hugo Louro < >>>>>>>>>>>>> hmclo...@gmail.com >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I think it would facilitate more frequent >>> releases >>>>>> to >>>>>>>>>>>>>>> summarize >>>>>>>>>>>>>>>>>>>>> in a >>>>>>>>>>>>>>>>>>>>>>>>> page >>>>>>>>>>>>>>>>>>>>>>>>>>>> the testing that all contributors/committers do >>> in >>>>>>>>>>>>>>> anticipation >>>>>>>>>>>>>>>>>>>>> of the >>>>>>>>>>>>>>>>>>>>>>>>>>>> release, plus any "new" testing that may become >>>>>> relevant >>>>>>>>>>>>> for >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> newer >>>>>>>>>>>>>>>>>>>>>>>>>>>> releases. Doing so would make it easy to create a >>>>>> check >>>>>>>>>>>>> form >>>>>>>>>>>>>>> or or >>>>>>>>>>>>>>>>>>>>>>>>> email >>>>>>>>>>>>>>>>>>>>>>>>>>>> template that what we feel should be done to >>>>>> guarantee a >>>>>>>>>>>>>>> stable >>>>>>>>>>>>>>>>>>>>>>>>> release. >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>>>>>>>>>>>>>>>> Hugo >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Jul 29, 2019 at 7:15 AM Ethan Li < >>>>>>>>>>>>>>>>>>>>> ethanopensou...@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it. >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde >>> Døssing < >>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoess...@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think ideally we've been trying for semver, >>>>>> but it's >>>>>>>>>>>>> been >>>>>>>>>>>>>>>>>>>>> pretty >>>>>>>>>>>>>>>>>>>>>>>>>>> loose, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> e.g. there were breaking changes in one of the >>>>>> 1.2.x >>>>>>>>>>>>>>> releases >>>>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> storm-kafka-client. I don't know what rules >>> we've >>>>>>>>>>>>> actually >>>>>>>>>>>>>>> been >>>>>>>>>>>>>>>>>>>>>>>>> using, >>>>>>>>>>>>>>>>>>>>>>>>>>> if >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> any. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Semver for binary compatibility would probably >>>>>> be a good >>>>>>>>>>>>>>> rule of >>>>>>>>>>>>>>>>>>>>>>>>> thumb. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 20.01 skrev Ethan >>> Li < >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensou...@gmail.com>: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Stig, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Do you know what’s the versioning standard we >>>>>> have been >>>>>>>>>>>>>>>>>>>>> following >>>>>>>>>>>>>>>>>>>>>>>>> (to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> determine a 2.0.1 release or 2.1.0 release) ? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 12:26 PM, Stig Rohde >>>>>> Døssing < >>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoess...@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan >>>>>> Li < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensou...@gmail.com>: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It’s good idea to do more frequent release. >>> I >>>>>> can run >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> next >>>>>>>>>>>>>>>>>>>>>>>>>>>>> release. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I will take a look at both PRs. Other than >>>>>> that, I >>>>>>>>>>>>>>> think we >>>>>>>>>>>>>>>>>>>>> should >>>>>>>>>>>>>>>>>>>>>>>>>>>>> also >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> get >>> https://github.com/apache/storm/pull/3093 >>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3093> >>>>>> in the >>>>>>>>>>>>> new >>>>>>>>>>>>>>>>>>>>> release. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 11:58 AM, Stig Rohde >>>>>> Døssing < >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoess...@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think we've talked about more frequent >>>>>> releases >>>>>>>>>>>>>>> before. >>>>>>>>>>>>>>>>>>>>>>>>> Releasing >>>>>>>>>>>>>>>>>>>>>>>>>>>>> new >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> versions every few months means people >>> don't >>>>>> have to >>>>>>>>>>>>>>> wait >>>>>>>>>>>>>>>>>>>>> long >>>>>>>>>>>>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fixes >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> get out, and smaller releases are probably >>>>>> also >>>>>>>>>>>>> easier >>>>>>>>>>>>>>> for >>>>>>>>>>>>>>>>>>>>> users >>>>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>>>>> get >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> grips with (the fix list for 2.0.0 is >>>>>> enormous). >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> With that in mind, I think we should start >>>>>> looking at >>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>>>>>> next >>>>>>>>>>>>>>>>>>>>>>>>> 2.x >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (2.0.1 or 2.1.0?), since it's been a couple >>>>>> of months >>>>>>>>>>>>>>> since >>>>>>>>>>>>>>>>>>>>> 2.0.0 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> released. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The fix list would be >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>> >>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Govind and Ethan have offered to run the >>> next >>>>>>>>>>>>> release, >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>> help >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> validate >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> our release process guidelines. Would one >>> of >>>>>> you have >>>>>>>>>>>>>>> time >>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>> work >>>>>>>>>>>>>>>>>>>>>>>>>>>>> on a >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release in the near future? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It would be good to take a look at >>> currently >>>>>> open PRs >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>>>>>> decide >>>>>>>>>>>>>>>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> we >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> feel need to get merged before the next >>>>>> release. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would like to see at least >>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2990 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> merged >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878 >>>>>> seems like >>>>>>>>>>>>>>> it's >>>>>>>>>>>>>>>>>>>>> close >>>>>>>>>>>>>>>>>>>>>>>>> to >>>>>>>>>>>>>>>>>>>>>>>>>>>>> be >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mergeable too? >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>> >>> >
