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