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