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? >> >>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>>> >> >>>>>>>>>>>>>>> >> >>>>>>>>>>>> >> >>>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>> >> >>>> >> >>> >> >> >> > >> >>
