Makes sense. I'll take a look at it. Ideally I'd want the license files to just not include org.apache.storm artifacts. I don't think we need to tell people that the project depends on itself.
If we can exclude these artifacts from the lists, I don't think the release plugin needs to update these files. Den tir. 13. aug. 2019 kl. 17.36 skrev Ethan Li <ethanopensou...@gmail.com>: > 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? > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >>> > >
