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