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