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