You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@storm.apache.org by Stig Rohde Døssing <st...@gmail.com> on 2019/08/01 09:19:44 UTC
Re: [DISCUSS] Next 2.x release
Thanks Ethan, yes 2.1.0 makes sense.
Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <et...@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 <hm...@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 <et...@gmail.com>
> wrote:
> >
> >> Thanks Stig. I will look into it.
> >>
> >>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
> stigdoessing@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 <
> >> ethanopensource@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 <
> >> stigdoessing@gmail.com>
> >>>> wrote:
> >>>>>
> >>>>> Sounds great, thanks Ethan.
> >>>>>
> >>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
> >>>> ethanopensource@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 <
> >>>> stigdoessing@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?
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: [DISCUSS] Next 2.x release
Posted by Stig Rohde Døssing <st...@gmail.com>.
Sounds good
Den ons. 21. aug. 2019 kl. 17.27 skrev Ethan Li <et...@gmail.com>:
> As we agreed to create a 2.1.x-branch and any later critical bug fixes for
> 2.1.x will go into that branch, I think there is not point for master
> branch to freeze.
>
> There are many pull requests I’d like to merge and it potentially blocks
> some of our developments (for up to 20 days now). So I am proposing to free
> master branch and start merging pull requests. And if it’s a critical bug
> fix, we should merge it to 2.1.x-branch too.
>
> > On Aug 19, 2019, at 3:01 PM, Ethan Li <et...@gmail.com> wrote:
> >
> > Yes we can revert the two commits before merging in a new commit if we
> decide to include this new commit to current version.
> >
> >
> >> On Aug 19, 2019, at 2:57 PM, Stig Rohde Døssing <stigdoessing@gmail.com
> <ma...@gmail.com>> wrote:
> >>
> >>> Now if we need to merge something in (2.1.0 is not released yet), we
> >> merge it to 2.1.x-branch. But the current pom version is
> 2.1.1-SNAPSHOT,
> >> which should really be 2.1.0-SNAPSHOT, because this commit goes into
> 2.1.0
> >> version. To fix this, we need to revert last two commits before we
> merge
> >> the new commit.
> >>
> >> Sure, but if we're merging anything to 2.1.x-branch during the release
> >> process, we're either expecting it to go in 2.1.1 so 2.1.1-SNAPSHOT is
> the
> >> right version, or we're cancelling the 2.1.0 vote in order to include
> it,
> >> and in that case we're reverting those two commits anyway, right? I
> don't
> >> think there's a problem with merging something in, and then reverting
> the
> >> version bump in a later commit?
> >>
> >> Den man. 19. aug. 2019 kl. 20.38 skrev Ethan Li <
> ethanopensource@gmail.com <ma...@gmail.com>>:
> >>
> >>> You are right. But I was talking about the pom version.
> >>>
> >>> So if we have 2.1.x-branch and the pom version is 2.1.0-SNAPSHOT. If we
> >>> start release process here, i.e. run “mvn release:prepare”, it will
> create
> >>> and push two commits automatically.
> >>>
> >>> First commit: change pom version to 2.1.0; and create a v2.1.0 git tag.
> >>> Second commit: change pom version to 2.1.1-SNAPSHOT.
> >>>
> >>> So now in 2.1.x-branch, the pom version is 2.1.1-SNAPSHOT.
> >>>
> >>> Now if we need to merge something in (2.1.0 is not released yet), we
> merge
> >>> it to 2.1.x-branch. But the current pom version is 2.1.1-SNAPSHOT,
> which
> >>> should really be 2.1.0-SNAPSHOT, because this commit goes into 2.1.0
> >>> version. To fix this, we need to revert last two commits before we
> merge
> >>> the new commit.
> >>>
> >>> If we use 2.1-SNAPSHOT, we don’t need to revert.
> >>>
> >>> With that being said, I am fine with reverting if needed. It’s
> probably
> >>> safe to not change the convention.
> >>>
> >>>
> >>>
> >>>> On Aug 19, 2019, at 1:24 PM, Stig Rohde Døssing <
> stigdoessing@gmail.com <ma...@gmail.com>>
> >>> wrote:
> >>>>
> >>>> Ok, that makes sense. I still don't understand the need for
> 2.1-SNAPSHOT?
> >>>>
> >>>> If we branch off 2.1.x-branch and then roll master to 2.2.0-SNAPSHOT
> >>>> immediately, we can merge any commits into master and mark them in
> Jira
> >>>> with fix version 2.2.0. If we then get a bugfix that needs to go in
> e.g.
> >>>> 2.1.1, we can merge it to master and cherry pick the commit back to
> >>>> 2.1.x-branch, and update the fix version to both 2.2.0 and 2.1.1.
> This is
> >>>> basically similar to how it worked for the 1.x-branch branches.
> >>>>
> >>>> Why do we need 2.1-SNAPSHOT?
> >>>>
> >>>> Den man. 19. aug. 2019 kl. 20.03 skrev Ethan Li <
> >>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:
> ethanopensource@gmail.com <ma...@gmail.com>>>:
> >>>>
> >>>>> We don’t create 2.1.0 branch.
> >>>>>
> >>>>> I was thinking (and have been doing) about creating a 2.1.x-branch
> >>> before
> >>>>> doing any thing release related. Then we use 2.1.x-branch to release
> >>>>> 2.1.0, and 2.1.1, etc.
> >>>>>
> >>>>> When we create a 2.1.x-branch, we move master to 2.2.x-branch. It’s
> a
> >>>>> little different than what we did in the past. But it makes more
> sense
> >>> as
> >>>>> it follows semantic versioning more strictly.
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On Aug 19, 2019, at 12:53 PM, Stig Rohde Døssing <
> >>> stigdoessing@gmail.com <ma...@gmail.com>>
> >>>>> wrote:
> >>>>>>
> >>>>>> I would be fine with just freezing (non-critical) merges during the
> >>>>>> release process. These mails are public, so it's easy for anyone to
> see
> >>>>>> whether a release is in progress.
> >>>>>>
> >>>>>> If we want to do merges while releases are going on, I think your
> >>>>> proposal
> >>>>>> of using a release branch is fine. I'm not sure I understand why we
> >>> need
> >>>>>> the 2.1-SNAPSHOT version though?
> >>>>>>
> >>>>>> Let's say we create release branch 2.1.0-branch from master. We roll
> >>> the
> >>>>>> master version to 2.1.1-SNAPSHOT (for example) after the 2.1.0
> branch
> >>> is
> >>>>>> created. We then get a bug fix that should go in 2.1.0. In this
> case we
> >>>>>> should merge it to 2.1.0-branch, then merge 2.1.0-branch to master.
> In
> >>>>> Jira
> >>>>>> we mark it as going in 2.1.0.
> >>>>>>
> >>>>>> We then get a PR that shouldn't be included in 2.1.0. We just merge
> it
> >>> to
> >>>>>> master, and mark it as 2.1.1 in Jira.
> >>>>>>
> >>>>>> Finally once 2.1.0 is released, we merge 2.1.0-branch into master
> and
> >>>>>> delete 2.1.0-branch.
> >>>>>>
> >>>>>> Why is there a need to 2.1-SNAPSHOT?
> >>>>>>
> >>>>>> Den man. 19. aug. 2019 kl. 18.15 skrev Ethan Li <
> >>>>> ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
> <mailto:
> >>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:
> ethanopensource@gmail.com <ma...@gmail.com>>>>:
> >>>>>>
> >>>>>>> Many issues came up while I was preparing for 2.1.0 release.
> Freezing
> >>>>>>> merge until the release is done is not practical. So I am
> proposing:
> >>>>>>>
> >>>>>>> 1. Once we decide to make a release, we create a new branch based
> on
> >>>>>>> master and start release process.
> >>>>>>> 2. During the new process, master is still open for backwards
> >>>>>>> compatibility commits, including new features, bu g fixes, etc.
> >>>>>>> 3. Only bug fixes will be merged to the new branch and we need to
> >>>>> restart
> >>>>>>> the release process to include the bug fixes.
> >>>>>>> 4. To avoid too much confusion on pom versions when we merge new
> >>> commits
> >>>>>>> during the release process, we should use less concrete version.
> For
> >>>>>>> example, in 2.1.x-branch, the pom version should be 2.1-SNAPSHOT,
> >>>>> instead
> >>>>>>> of 2.1.0-SNAPSHOT.
> >>>>>>>
> >>>>>>> For example,
> >>>>>>>
> >>>>>>> Let’s say we have a new branch 2.1.x-branch, the pom version is
> >>>>>>> 2.1.0-SNAPSHOT. We start the release process and after running the
> mvn
> >>>>>>> release:prepare -Pxxx command, the pom version changes to
> >>>>> 2.1.1-SNAPSHOT,
> >>>>>>> and before that a git tag v2.1.0 is created. Now if there is a bug
> >>> fix
> >>>>> we
> >>>>>>> have to merge in, so we merge in and it’s actually merged in to
> >>>>>>> 2.1.1-SNAPSHOT at this point if we don’t manually revert the pom
> >>>>> version,
> >>>>>>> which can be confusing. We can avoid this problem by just using
> >>>>>>> 2.1-SNAPSHOT as the pom version. So it doesn’t have to change.
> >>>>>>>
> >>>>>>> Please let me know if there is any potential risk for doing this.
> >>>>>>>
> >>>>>>> Thanks
> >>>>>>> Ethan
> >>>>>>>
> >>>>>>>> On Aug 19, 2019, at 10:25 AM, Ethan Li <ethanopensource@gmail.com
> <ma...@gmail.com>
> >>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> The pull request for the fix is
> >>>>>>> https://github.com/apache/storm/pull/3106 <
> https://github.com/apache/storm/pull/3106> <
> >>> https://github.com/apache/storm/pull/3106 <
> https://github.com/apache/storm/pull/3106>> <
> >>>>>>> https://github.com/apache/storm/pull/3106 <
> https://github.com/apache/storm/pull/3106> <
> >>> https://github.com/apache/storm/pull/3106 <
> https://github.com/apache/storm/pull/3106>> <
> >>>>> https://github.com/apache/storm/pull/3106 <
> https://github.com/apache/storm/pull/3106> <
> >>> https://github.com/apache/storm/pull/3106 <
> https://github.com/apache/storm/pull/3106>>>>
> >>>>>>>>
> >>>>>>>>> On Aug 19, 2019, at 10:15 AM, Ethan Li <
> ethanopensource@gmail.com <ma...@gmail.com>
> >>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
> >>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
> >>>>>>> <mailto:ethanopensource@gmail.com <mailto:
> ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:
> ethanopensource@gmail.com>>
> >>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>>
> >>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> So I was preparing for a new release candidate i.e. rc3. I can
> build
> >>>>> it
> >>>>>>> from source without any problem. Then I set up a standalone cluster
> >>> and
> >>>>>>> submitted a WordCountTopology. The workers kept restarting because
> of
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> 2019-08-19 15:09:49.635 o.a.s.t.ShellBolt Thread-30 [ERROR]
> Halting
> >>>>>>> process: ShellBolt died. Command: [python, splitsentence.py],
> >>>>> ProcessInfo
> >>>>>>> pid:3756, name:split exitCode:-1, errorString:
> >>>>>>>>> java.lang.IllegalArgumentException: command sync is not supported
> >>>>>>>>> at
> >>>>>>>
> >>>>>
> >>>
> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
> >>>>>>> [storm-client-2.1.0.jar:2.1.0]
> >>>>>>>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
> >>>>>>>>> 2019-08-19 15:09:49.635 o.a.s.e.e.ReportError Thread-30 [ERROR]
> >>> Error
> >>>>>>>>> java.lang.IllegalArgumentException: command sync is not supported
> >>>>>>>>> at
> >>>>>>>
> >>>>>
> >>>
> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
> >>>>>>> [storm-client-2.1.0.jar:2.1.0]
> >>>>>>>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
> >>>>>>>>> 2019-08-19 15:09:49.636 o.a.s.t.ShellBolt Thread-28 [ERROR]
> Halting
> >>>>>>> process: ShellBolt died. Command: [python, splitsentence.py],
> >>>>> ProcessInfo
> >>>>>>> pid:3755, name:split exitCode:-1, errorString:
> >>>>>>>>> java.lang.IllegalArgumentException: command sync is not supported
> >>>>>>>>> at
> >>>>>>>
> >>>>>
> >>>
> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
> >>>>>>> [storm-client-2.1.0.jar:2.1.0]
> >>>>>>>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
> >>>>>>>>> 2019-08-19 15:09:49.637 o.a.s.e.e.ReportError Thread-28 [ERROR]
> >>> Error
> >>>>>>>>> java.lang.IllegalArgumentException: command sync is not supported
> >>>>>>>>> at
> >>>>>>>
> >>>>>
> >>>
> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
> >>>>>>> [storm-client-2.1.0.jar:2.1.0]
> >>>>>>>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> <
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> >
> >>> <
> >>>
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> <
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> >
> >>>>
> >>>>> <
> >>>>>
> >>>
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> <
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> >
> >>> <
> >>>
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> <
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> >
> >>>>
> >>>>>>
> >>>>>>> <
> >>>>>>>
> >>>>>
> >>>
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> <
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> >
> >>> <
> >>>
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> <
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> >
> >>>>
> >>>>> <
> >>>>>
> >>>
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> <
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> >
> >>> <
> >>>
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> <
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> >
> >>>>
> >>>>>>>
> >>>>>>> I believe we shouldn’t throw exceptions here.
> >>>>>>>>>
> >>>>>>>>> Will make a pull request to fix it.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> On Aug 14, 2019, at 11:11 PM, Ethan Li <
> ethanopensource@gmail.com <ma...@gmail.com>
> >>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
> >>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
> >>>>>>> <mailto:ethanopensource@gmail.com <mailto:
> ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:
> ethanopensource@gmail.com>>
> >>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>>
> >>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Hi Taylor,
> >>>>>>>>>>
> >>>>>>>>>> Mostly I was able to follow the doc
> >>>>>>>
> >>>>>
> >>>
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> >
> >>> <
> >>>
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> >
> >>>>
> >>>>> <
> >>>>>
> >>>
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> >
> >>> <
> >>>
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> >
> >>>>
> >>>>>>
> >>>>>>> <
> >>>>>>>
> >>>>>
> >>>
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> >
> >>> <
> >>>
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> >
> >>>>
> >>>>> <
> >>>>>
> >>>
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> >
> >>> <
> >>>
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> >
> >>>>
> >>>>>>> ,
> >>>>>>> except:
> >>>>>>>>>>
> >>>>>>>>>> For Step 1, I used the following command as suggested.
> >>>>>>>>>> mvn release:prepare -P dist,rat,externals,examples
> >>>>>>>>>> mvn release:perform -P dist,rat,externals,examples
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> For Step3, I had to run "git checkout tags/v2.1.0 -b v2.1.0” so
> >>> that
> >>>>>>> I can run “mvn package” for storm-dist/binary and storm-dist/source
> >>>>> based
> >>>>>>> on v2.1.0. Otherwise if I run “mvn package” on 2.1.x-branch, it
> will
> >>>>> fail
> >>>>>>> because the pom version is “2.1.x-SNAPSHOT”.
> >>>>>>>>>>
> >>>>>>>>>> Then I find packages in storm-dist/binary/final-package/target
> and
> >>>>>>> storm-dist/source/target, sign them, generate checksum and copy
> them
> >>> to
> >>>>> svn.
> >>>>>>>>>>
> >>>>>>>>>> I think there are something I should do. But please let me know
> if
> >>> I
> >>>>>>> was doing something wrong. I will also update the doc after the
> >>>>> release
> >>>>>>> is complete. Thank you very much!
> >>>>>>>>>>
> >>>>>>>>>> Ethan
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> On Aug 14, 2019, at 12:24 PM, Ethan Li <
> ethanopensource@gmail.com <ma...@gmail.com>
> >>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
> >>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
> >>>>>>> <mailto:ethanopensource@gmail.com <mailto:
> ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:
> ethanopensource@gmail.com>>
> >>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>>
> >>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> I am continuing for another release candidate since the pr is
> >>>>> merged.
> >>>>>>>>>>>
> >>>>>>>>>>>> On Aug 13, 2019, at 11:58 AM, Stig Rohde Døssing <
> >>>>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:
> stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
> >>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:
> stigdoessing@gmail.com <ma...@gmail.com>>> <mailto:
> >>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:
> stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
> >>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:
> stigdoessing@gmail.com <ma...@gmail.com>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Updated https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053> <
> >>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053>> <
> >>>>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053> <
> >>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053>>> <
> >>>>>>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053> <
> >>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053>> <
> >>>>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053> <
> >>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053>>>> so we don't have
> >>>>>>>>>>>> org.apache.storm artifacts in the DEPENDENCY-LICENSES file.
> It's
> >>>>>>> ready for
> >>>>>>>>>>>> review if someone wants to look at it.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Den tir. 13. aug. 2019 kl. 18.21 skrev Ethan Li <
> >>>>>>> ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
> <mailto:
> >>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:
> ethanopensource@gmail.com <ma...@gmail.com>>> <mailto:
> >>>>> ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
> <mailto:
> >>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:
> ethanopensource@gmail.com <ma...@gmail.com>>>>>:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Thank you, Taylor. Will delete them.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <
> >>> ptgoetz@gmail.com <ma...@gmail.com> <mailto:ptgoetz@gmail.com
> <ma...@gmail.com>>
> >>>>> <mailto:ptgoetz@gmail.com <ma...@gmail.com> <mailto:
> ptgoetz@gmail.com <ma...@gmail.com>>>
> >>>>>>> <mailto:ptgoetz@gmail.com <ma...@gmail.com> <mailto:
> ptgoetz@gmail.com <ma...@gmail.com>> <mailto:
> >>> ptgoetz@gmail.com <ma...@gmail.com> <mailto:ptgoetz@gmail.com
> <ma...@gmail.com>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Those can be safely deleted.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> -Taylor
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Aug 13, 2019, at 12:15 PM, Ethan Li <
> >>>>> ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
> <mailto:
> >>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:
> ethanopensource@gmail.com <ma...@gmail.com>>>
> >>>>>>> <mailto:ethanopensource@gmail.com <mailto:
> ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:
> ethanopensource@gmail.com>>
> >>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Do we need/want to clean up the release candidate from
> >>>>>>>>>>>>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm> <
> >>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm>> <
> >>>>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm> <
> >>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm>>> <
> >>>>>>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm> <
> >>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm>> <
> >>>>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm> <
> >>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm>>>> <
> >>>>>>>>>>>>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm> <
> >>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm>> <
> >>>>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm> <
> >>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm>>> <
> >>>>>>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm> <
> >>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm>> <
> >>>>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm> <
> >>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm>>>>> ?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>> <
> >>>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>>>
> >>>>> <
> >>>>>
> >>>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>> <
> >>>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>>>
> >>>>>>
> >>>>>>> <
> >>>>>>>
> >>>>>
> >>>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>> <
> >>>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>>>
> >>>>> <
> >>>>>
> >>>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>> <
> >>>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>>>
> >>>>>>
> >>>>>>>>
> >>>>>>>>>>>>> <
> >>>>>>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>> <
> >>>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>>>
> >>>>> <
> >>>>>
> >>>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>> <
> >>>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>>>
> >>>>>>
> >>>>>>> <
> >>>>>>>
> >>>>>
> >>>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>> <
> >>>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>>>
> >>>>> <
> >>>>>
> >>>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>> <
> >>>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>>>
> >>>>>>
> >>>>>>>>>
> >>>>>>>>>>>>> says we do. But we have a lot of rc in
> >>>>>>>>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/> <
> >>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/>> <
> >>>>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/> <
> >>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/>>> <
> >>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/> <
> >>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/>> <
> >>>>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/> <
> >>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/>>>> <
> >>>>>>>>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/> <
> >>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/>> <
> >>>>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/> <
> >>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/>>> <
> >>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/> <
> >>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/>> <
> >>>>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/> <
> >>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Just want to be absolutely sure about this. Thanks.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Aug 13, 2019, at 10:56 AM, Ethan Li <
> >>>>>>> ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
> <mailto:
> >>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:
> ethanopensource@gmail.com <ma...@gmail.com>>> <mailto:
> >>>>> ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
> <mailto:
> >>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:
> ethanopensource@gmail.com <ma...@gmail.com>>>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> That sounds better. It will be easier for release. Thank
> you
> >>>>> for
> >>>>>>>>>>>>> looking into this.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Aug 13, 2019, at 10:54 AM, Stig Rohde Døssing <
> >>>>>>>>>>>>> stigdoessing@gmail.com <ma...@gmail.com>
> <mailto:stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
> >>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:
> stigdoessing@gmail.com <ma...@gmail.com>>> <mailto:
> >>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:
> stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
> >>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:
> stigdoessing@gmail.com <ma...@gmail.com>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 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 <
> >>>>>>>>>>>>> ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
> >>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
> >>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
> >>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@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 <
> >>>>>>>>>>>>> stigdoessing@gmail.com <ma...@gmail.com>
> <mailto:stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
> >>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:
> stigdoessing@gmail.com <ma...@gmail.com>>> <mailto:
> >>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:
> stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
> >>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:
> stigdoessing@gmail.com <ma...@gmail.com>>>>>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Oops, sorry that's not right. The license plugin setup
> was
> >>>>>>> disabled
> >>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3031 <
> https://github.com/apache/storm/pull/3031> <
> >>> https://github.com/apache/storm/pull/3031 <
> https://github.com/apache/storm/pull/3031>> <
> >>>>> https://github.com/apache/storm/pull/3031 <
> https://github.com/apache/storm/pull/3031> <
> >>> https://github.com/apache/storm/pull/3031 <
> https://github.com/apache/storm/pull/3031>>> <
> >>>>>>> https://github.com/apache/storm/pull/3031 <
> https://github.com/apache/storm/pull/3031> <
> >>> https://github.com/apache/storm/pull/3031 <
> https://github.com/apache/storm/pull/3031>> <
> >>>>> https://github.com/apache/storm/pull/3031 <
> https://github.com/apache/storm/pull/3031> <
> >>> https://github.com/apache/storm/pull/3031 <
> 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 <
> https://github.com/apache/storm/pull/3053> <
> >>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053>> <
> >>>>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053> <
> >>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053>>> <
> >>>>>>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053> <
> >>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053>> <
> >>>>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053> <
> >>> https://github.com/apache/storm/pull/3053 <
> 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
> >>> <
> >>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com <ma...@gmail.com>
> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>
> >>> <mailto:stigdoessing@gmail.com <ma...@gmail.com>
> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>>
> >>>>> <mailto:stigdoessing@gmail.com <ma...@gmail.com>
> <mailto:stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
> >>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:
> stigdoessing@gmail.com <ma...@gmail.com>>>>>:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> There's a script that can help you do it in
> >>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053> <
> >>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053>> <
> >>>>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053> <
> >>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053>>> <
> >>>>>>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053> <
> >>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053>> <
> >>>>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053> <
> >>> https://github.com/apache/storm/pull/3053 <
> 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 <
> >>>>>>>>>>>>>>>>>> ethanopensource@gmail.com <mailto:
> ethanopensource@gmail.com> <mailto:
> >>> ethanopensource@gmail.com <ma...@gmail.com>> <mailto:
> ethanopensource@gmail.com <ma...@gmail.com> <mailto:
> >>> ethanopensource@gmail.com <ma...@gmail.com>>>
> >>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
> >>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@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?> <
> >>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>> <
> >>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
> >>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>>> <
> >>>>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
> >>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>> <
> >>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
> >>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>>>>
> >>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
> >>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>> <
> >>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
> >>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>>> <
> >>>>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
> >>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>> <
> >>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
> >>> 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 <
> >>>>>>> ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
> <mailto:
> >>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:
> ethanopensource@gmail.com <ma...@gmail.com>>> <mailto:
> >>>>> ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
> <mailto:
> >>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:
> ethanopensource@gmail.com <ma...@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 <
> >>>>>>> ptgoetz@gmail.com <ma...@gmail.com> <mailto:
> ptgoetz@gmail.com <ma...@gmail.com>> <mailto:
> >>> ptgoetz@gmail.com <ma...@gmail.com> <mailto:ptgoetz@gmail.com
> <ma...@gmail.com>>> <mailto:ptgoetz@gmail.com <mailto:
> ptgoetz@gmail.com>
> >>> <mailto:ptgoetz@gmail.com <ma...@gmail.com>>
> >>>>> <mailto:ptgoetz@gmail.com <ma...@gmail.com> <mailto:
> ptgoetz@gmail.com <ma...@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 <
> >>>>>>>>>>>>> ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
> >>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
> >>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
> >>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@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
> >
> >>> <
> >>>
> 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
> >
> >>>>
> >>>>> <
> >>>>>
> >>>
> 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
> >
> >>> <
> >>>
> 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
> >>>>> <
> >>>>>
> >>>
> 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
> >>>>>>> <
> >>>>>>>
> >>>>>
> >>>
> 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 <
> >>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>> ptgoetz@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 <
> >>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
> >>>>>>>>>>>>>>>>>>>>> ethanopensource@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
> >>> <
> >>>>>>>>>>>>>>>>>>>>> stigdoessing@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
> >>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>> dagit@apache.org
> >>>>>>>>>>>>>>>>>>>>> <mailto:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dagit@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
> <
> >>>>>>>>>>>>> dagit@apache.org
> >>>>>>>>>>>>>>>>>>>>> <mailto:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dagit@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> dagit@apache.org
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <ma...@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig
> >>> Rohde
> >>>>>>> Døssing
> >>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan
> W.
> >>>>> Call
> >>>>>>> <
> >>>>>>>>>>>>>>>>>>>>> bcall@apache.org
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <mailto:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bcall@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes
> sense.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43
> >>> skrev
> >>>>>>> Ethan
> >>>>>>>>>>>>> Li <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> hmclouro@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into
> it.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM,
> >>> Stig
> >>>>>>> Rohde
> >>>>>>>>>>>>>>>>>> Døssing <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl.
> >>> 19.16
> >>>>>>> skrev
> >>>>>>>>>>>>> Ethan
> >>>>>>>>>>>>>>>>>>>>> Li <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
> >
>
>
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@gmail.com>.
As we agreed to create a 2.1.x-branch and any later critical bug fixes for 2.1.x will go into that branch, I think there is not point for master branch to freeze.
There are many pull requests I’d like to merge and it potentially blocks some of our developments (for up to 20 days now). So I am proposing to free master branch and start merging pull requests. And if it’s a critical bug fix, we should merge it to 2.1.x-branch too.
> On Aug 19, 2019, at 3:01 PM, Ethan Li <et...@gmail.com> wrote:
>
> Yes we can revert the two commits before merging in a new commit if we decide to include this new commit to current version.
>
>
>> On Aug 19, 2019, at 2:57 PM, Stig Rohde Døssing <stigdoessing@gmail.com <ma...@gmail.com>> wrote:
>>
>>> Now if we need to merge something in (2.1.0 is not released yet), we
>> merge it to 2.1.x-branch. But the current pom version is 2.1.1-SNAPSHOT,
>> which should really be 2.1.0-SNAPSHOT, because this commit goes into 2.1.0
>> version. To fix this, we need to revert last two commits before we merge
>> the new commit.
>>
>> Sure, but if we're merging anything to 2.1.x-branch during the release
>> process, we're either expecting it to go in 2.1.1 so 2.1.1-SNAPSHOT is the
>> right version, or we're cancelling the 2.1.0 vote in order to include it,
>> and in that case we're reverting those two commits anyway, right? I don't
>> think there's a problem with merging something in, and then reverting the
>> version bump in a later commit?
>>
>> Den man. 19. aug. 2019 kl. 20.38 skrev Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>>:
>>
>>> You are right. But I was talking about the pom version.
>>>
>>> So if we have 2.1.x-branch and the pom version is 2.1.0-SNAPSHOT. If we
>>> start release process here, i.e. run “mvn release:prepare”, it will create
>>> and push two commits automatically.
>>>
>>> First commit: change pom version to 2.1.0; and create a v2.1.0 git tag.
>>> Second commit: change pom version to 2.1.1-SNAPSHOT.
>>>
>>> So now in 2.1.x-branch, the pom version is 2.1.1-SNAPSHOT.
>>>
>>> Now if we need to merge something in (2.1.0 is not released yet), we merge
>>> it to 2.1.x-branch. But the current pom version is 2.1.1-SNAPSHOT, which
>>> should really be 2.1.0-SNAPSHOT, because this commit goes into 2.1.0
>>> version. To fix this, we need to revert last two commits before we merge
>>> the new commit.
>>>
>>> If we use 2.1-SNAPSHOT, we don’t need to revert.
>>>
>>> With that being said, I am fine with reverting if needed. It’s probably
>>> safe to not change the convention.
>>>
>>>
>>>
>>>> On Aug 19, 2019, at 1:24 PM, Stig Rohde Døssing <stigdoessing@gmail.com <ma...@gmail.com>>
>>> wrote:
>>>>
>>>> Ok, that makes sense. I still don't understand the need for 2.1-SNAPSHOT?
>>>>
>>>> If we branch off 2.1.x-branch and then roll master to 2.2.0-SNAPSHOT
>>>> immediately, we can merge any commits into master and mark them in Jira
>>>> with fix version 2.2.0. If we then get a bugfix that needs to go in e.g.
>>>> 2.1.1, we can merge it to master and cherry pick the commit back to
>>>> 2.1.x-branch, and update the fix version to both 2.2.0 and 2.1.1. This is
>>>> basically similar to how it worked for the 1.x-branch branches.
>>>>
>>>> Why do we need 2.1-SNAPSHOT?
>>>>
>>>> Den man. 19. aug. 2019 kl. 20.03 skrev Ethan Li <
>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>:
>>>>
>>>>> We don’t create 2.1.0 branch.
>>>>>
>>>>> I was thinking (and have been doing) about creating a 2.1.x-branch
>>> before
>>>>> doing any thing release related. Then we use 2.1.x-branch to release
>>>>> 2.1.0, and 2.1.1, etc.
>>>>>
>>>>> When we create a 2.1.x-branch, we move master to 2.2.x-branch. It’s a
>>>>> little different than what we did in the past. But it makes more sense
>>> as
>>>>> it follows semantic versioning more strictly.
>>>>>
>>>>>
>>>>>
>>>>>> On Aug 19, 2019, at 12:53 PM, Stig Rohde Døssing <
>>> stigdoessing@gmail.com <ma...@gmail.com>>
>>>>> wrote:
>>>>>>
>>>>>> I would be fine with just freezing (non-critical) merges during the
>>>>>> release process. These mails are public, so it's easy for anyone to see
>>>>>> whether a release is in progress.
>>>>>>
>>>>>> If we want to do merges while releases are going on, I think your
>>>>> proposal
>>>>>> of using a release branch is fine. I'm not sure I understand why we
>>> need
>>>>>> the 2.1-SNAPSHOT version though?
>>>>>>
>>>>>> Let's say we create release branch 2.1.0-branch from master. We roll
>>> the
>>>>>> master version to 2.1.1-SNAPSHOT (for example) after the 2.1.0 branch
>>> is
>>>>>> created. We then get a bug fix that should go in 2.1.0. In this case we
>>>>>> should merge it to 2.1.0-branch, then merge 2.1.0-branch to master. In
>>>>> Jira
>>>>>> we mark it as going in 2.1.0.
>>>>>>
>>>>>> We then get a PR that shouldn't be included in 2.1.0. We just merge it
>>> to
>>>>>> master, and mark it as 2.1.1 in Jira.
>>>>>>
>>>>>> Finally once 2.1.0 is released, we merge 2.1.0-branch into master and
>>>>>> delete 2.1.0-branch.
>>>>>>
>>>>>> Why is there a need to 2.1-SNAPSHOT?
>>>>>>
>>>>>> Den man. 19. aug. 2019 kl. 18.15 skrev Ethan Li <
>>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>> <mailto:
>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>:
>>>>>>
>>>>>>> Many issues came up while I was preparing for 2.1.0 release. Freezing
>>>>>>> merge until the release is done is not practical. So I am proposing:
>>>>>>>
>>>>>>> 1. Once we decide to make a release, we create a new branch based on
>>>>>>> master and start release process.
>>>>>>> 2. During the new process, master is still open for backwards
>>>>>>> compatibility commits, including new features, bu g fixes, etc.
>>>>>>> 3. Only bug fixes will be merged to the new branch and we need to
>>>>> restart
>>>>>>> the release process to include the bug fixes.
>>>>>>> 4. To avoid too much confusion on pom versions when we merge new
>>> commits
>>>>>>> during the release process, we should use less concrete version. For
>>>>>>> example, in 2.1.x-branch, the pom version should be 2.1-SNAPSHOT,
>>>>> instead
>>>>>>> of 2.1.0-SNAPSHOT.
>>>>>>>
>>>>>>> For example,
>>>>>>>
>>>>>>> Let’s say we have a new branch 2.1.x-branch, the pom version is
>>>>>>> 2.1.0-SNAPSHOT. We start the release process and after running the mvn
>>>>>>> release:prepare -Pxxx command, the pom version changes to
>>>>> 2.1.1-SNAPSHOT,
>>>>>>> and before that a git tag v2.1.0 is created. Now if there is a bug
>>> fix
>>>>> we
>>>>>>> have to merge in, so we merge in and it’s actually merged in to
>>>>>>> 2.1.1-SNAPSHOT at this point if we don’t manually revert the pom
>>>>> version,
>>>>>>> which can be confusing. We can avoid this problem by just using
>>>>>>> 2.1-SNAPSHOT as the pom version. So it doesn’t have to change.
>>>>>>>
>>>>>>> Please let me know if there is any potential risk for doing this.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Ethan
>>>>>>>
>>>>>>>> On Aug 19, 2019, at 10:25 AM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>
>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> The pull request for the fix is
>>>>>>> https://github.com/apache/storm/pull/3106 <https://github.com/apache/storm/pull/3106> <
>>> https://github.com/apache/storm/pull/3106 <https://github.com/apache/storm/pull/3106>> <
>>>>>>> https://github.com/apache/storm/pull/3106 <https://github.com/apache/storm/pull/3106> <
>>> https://github.com/apache/storm/pull/3106 <https://github.com/apache/storm/pull/3106>> <
>>>>> https://github.com/apache/storm/pull/3106 <https://github.com/apache/storm/pull/3106> <
>>> https://github.com/apache/storm/pull/3106 <https://github.com/apache/storm/pull/3106>>>>
>>>>>>>>
>>>>>>>>> On Aug 19, 2019, at 10:15 AM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>
>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
>>>>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>>
>>>>> wrote:
>>>>>>>>>
>>>>>>>>> So I was preparing for a new release candidate i.e. rc3. I can build
>>>>> it
>>>>>>> from source without any problem. Then I set up a standalone cluster
>>> and
>>>>>>> submitted a WordCountTopology. The workers kept restarting because of
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2019-08-19 15:09:49.635 o.a.s.t.ShellBolt Thread-30 [ERROR] Halting
>>>>>>> process: ShellBolt died. Command: [python, splitsentence.py],
>>>>> ProcessInfo
>>>>>>> pid:3756, name:split exitCode:-1, errorString:
>>>>>>>>> java.lang.IllegalArgumentException: command sync is not supported
>>>>>>>>> at
>>>>>>>
>>>>>
>>> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
>>>>>>> [storm-client-2.1.0.jar:2.1.0]
>>>>>>>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>>>>>>>>> 2019-08-19 15:09:49.635 o.a.s.e.e.ReportError Thread-30 [ERROR]
>>> Error
>>>>>>>>> java.lang.IllegalArgumentException: command sync is not supported
>>>>>>>>> at
>>>>>>>
>>>>>
>>> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
>>>>>>> [storm-client-2.1.0.jar:2.1.0]
>>>>>>>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>>>>>>>>> 2019-08-19 15:09:49.636 o.a.s.t.ShellBolt Thread-28 [ERROR] Halting
>>>>>>> process: ShellBolt died. Command: [python, splitsentence.py],
>>>>> ProcessInfo
>>>>>>> pid:3755, name:split exitCode:-1, errorString:
>>>>>>>>> java.lang.IllegalArgumentException: command sync is not supported
>>>>>>>>> at
>>>>>>>
>>>>>
>>> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
>>>>>>> [storm-client-2.1.0.jar:2.1.0]
>>>>>>>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>>>>>>>>> 2019-08-19 15:09:49.637 o.a.s.e.e.ReportError Thread-28 [ERROR]
>>> Error
>>>>>>>>> java.lang.IllegalArgumentException: command sync is not supported
>>>>>>>>> at
>>>>>>>
>>>>>
>>> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
>>>>>>> [storm-client-2.1.0.jar:2.1.0]
>>>>>>>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367>
>>> <
>>> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367>
>>>>
>>>>> <
>>>>>
>>> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367>
>>> <
>>> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367>
>>>>
>>>>>>
>>>>>>> <
>>>>>>>
>>>>>
>>> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367>
>>> <
>>> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367>
>>>>
>>>>> <
>>>>>
>>> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367>
>>> <
>>> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367>
>>>>
>>>>>>>
>>>>>>> I believe we shouldn’t throw exceptions here.
>>>>>>>>>
>>>>>>>>> Will make a pull request to fix it.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Aug 14, 2019, at 11:11 PM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>
>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
>>>>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>>
>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Taylor,
>>>>>>>>>>
>>>>>>>>>> Mostly I was able to follow the doc
>>>>>>>
>>>>>
>>> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>
>>> <
>>> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>
>>>>
>>>>> <
>>>>>
>>> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>
>>> <
>>> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>
>>>>
>>>>>>
>>>>>>> <
>>>>>>>
>>>>>
>>> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>
>>> <
>>> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>
>>>>
>>>>> <
>>>>>
>>> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>
>>> <
>>> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>
>>>>
>>>>>>> ,
>>>>>>> except:
>>>>>>>>>>
>>>>>>>>>> For Step 1, I used the following command as suggested.
>>>>>>>>>> mvn release:prepare -P dist,rat,externals,examples
>>>>>>>>>> mvn release:perform -P dist,rat,externals,examples
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> For Step3, I had to run "git checkout tags/v2.1.0 -b v2.1.0” so
>>> that
>>>>>>> I can run “mvn package” for storm-dist/binary and storm-dist/source
>>>>> based
>>>>>>> on v2.1.0. Otherwise if I run “mvn package” on 2.1.x-branch, it will
>>>>> fail
>>>>>>> because the pom version is “2.1.x-SNAPSHOT”.
>>>>>>>>>>
>>>>>>>>>> Then I find packages in storm-dist/binary/final-package/target and
>>>>>>> storm-dist/source/target, sign them, generate checksum and copy them
>>> to
>>>>> svn.
>>>>>>>>>>
>>>>>>>>>> I think there are something I should do. But please let me know if
>>> I
>>>>>>> was doing something wrong. I will also update the doc after the
>>>>> release
>>>>>>> is complete. Thank you very much!
>>>>>>>>>>
>>>>>>>>>> Ethan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Aug 14, 2019, at 12:24 PM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>
>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
>>>>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>>
>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I am continuing for another release candidate since the pr is
>>>>> merged.
>>>>>>>>>>>
>>>>>>>>>>>> On Aug 13, 2019, at 11:58 AM, Stig Rohde Døssing <
>>>>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>> <mailto:
>>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Updated https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>> <
>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>>> <
>>>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>> <
>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>>>> so we don't have
>>>>>>>>>>>> org.apache.storm artifacts in the DEPENDENCY-LICENSES file. It's
>>>>>>> ready for
>>>>>>>>>>>> review if someone wants to look at it.
>>>>>>>>>>>>
>>>>>>>>>>>> Den tir. 13. aug. 2019 kl. 18.21 skrev Ethan Li <
>>>>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>> <mailto:
>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>> <mailto:
>>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>> <mailto:
>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>>:
>>>>>>>>>>>>
>>>>>>>>>>>>> Thank you, Taylor. Will delete them.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <
>>> ptgoetz@gmail.com <ma...@gmail.com> <mailto:ptgoetz@gmail.com <ma...@gmail.com>>
>>>>> <mailto:ptgoetz@gmail.com <ma...@gmail.com> <mailto:ptgoetz@gmail.com <ma...@gmail.com>>>
>>>>>>> <mailto:ptgoetz@gmail.com <ma...@gmail.com> <mailto:ptgoetz@gmail.com <ma...@gmail.com>> <mailto:
>>> ptgoetz@gmail.com <ma...@gmail.com> <mailto:ptgoetz@gmail.com <ma...@gmail.com>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Those can be safely deleted.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> -Taylor
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Aug 13, 2019, at 12:15 PM, Ethan Li <
>>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>> <mailto:
>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
>>>>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Do we need/want to clean up the release candidate from
>>>>>>>>>>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>> <
>>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>>> <
>>>>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>> <
>>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>>>> <
>>>>>>>>>>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>> <
>>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>>> <
>>>>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>> <
>>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>>>>> ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>
>>>>>
>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>> <
>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>>
>>>>> <
>>>>>
>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>> <
>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>>
>>>>>>
>>>>>>> <
>>>>>>>
>>>>>
>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>> <
>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>>
>>>>> <
>>>>>
>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>> <
>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>>
>>>>>>
>>>>>>>>
>>>>>>>>>>>>> <
>>>>>>>>>>>>>
>>>>>>>
>>>>>
>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>> <
>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>>
>>>>> <
>>>>>
>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>> <
>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>>
>>>>>>
>>>>>>> <
>>>>>>>
>>>>>
>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>> <
>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>>
>>>>> <
>>>>>
>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>> <
>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>>
>>>>>>
>>>>>>>>>
>>>>>>>>>>>>> says we do. But we have a lot of rc in
>>>>>>>>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>> <
>>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>>> <
>>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>> <
>>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>>>> <
>>>>>>>>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>> <
>>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>>> <
>>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>> <
>>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Just want to be absolutely sure about this. Thanks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Aug 13, 2019, at 10:56 AM, Ethan Li <
>>>>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>> <mailto:
>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>> <mailto:
>>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>> <mailto:
>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> That sounds better. It will be easier for release. Thank you
>>>>> for
>>>>>>>>>>>>> looking into this.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Aug 13, 2019, at 10:54 AM, Stig Rohde Døssing <
>>>>>>>>>>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>> <mailto:
>>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
>>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@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 <
>>>>>>>>>>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>> <mailto:
>>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>>>>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Oops, sorry that's not right. The license plugin setup was
>>>>>>> disabled
>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031> <
>>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031>> <
>>>>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031> <
>>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031>>> <
>>>>>>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031> <
>>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031>> <
>>>>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031> <
>>> https://github.com/apache/storm/pull/3031 <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 <https://github.com/apache/storm/pull/3053> <
>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>> <
>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>>> <
>>>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>> <
>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>>> https://github.com/apache/storm/pull/3053 <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
>>> <
>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>
>>> <mailto:stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>>
>>>>> <mailto:stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>>>>:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> There's a script that can help you do it in
>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>> <
>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>>> <
>>>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>> <
>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>>> https://github.com/apache/storm/pull/3053 <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 <
>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:
>>> ethanopensource@gmail.com <ma...@gmail.com>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:
>>> ethanopensource@gmail.com <ma...@gmail.com>>>
>>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@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?> <
>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>> <
>>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>>> <
>>>>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>> <
>>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>>>>
>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>
>>>>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>> <
>>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>>> <
>>>>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>> <
>>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
>>> 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 <
>>>>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>> <mailto:
>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>> <mailto:
>>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>> <mailto:
>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@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 <
>>>>>>> ptgoetz@gmail.com <ma...@gmail.com> <mailto:ptgoetz@gmail.com <ma...@gmail.com>> <mailto:
>>> ptgoetz@gmail.com <ma...@gmail.com> <mailto:ptgoetz@gmail.com <ma...@gmail.com>>> <mailto:ptgoetz@gmail.com <ma...@gmail.com>
>>> <mailto:ptgoetz@gmail.com <ma...@gmail.com>>
>>>>> <mailto:ptgoetz@gmail.com <ma...@gmail.com> <mailto:ptgoetz@gmail.com <ma...@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 <
>>>>>>>>>>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
>>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@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>
>>> <
>>> 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>
>>>>
>>>>> <
>>>>>
>>> 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>
>>> <
>>> 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
>>>>> <
>>>>>
>>> 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
>>>>>>> <
>>>>>>>
>>>>>
>>> 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 <
>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>> ptgoetz@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 <
>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>> ethanopensource@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
>>> <
>>>>>>>>>>>>>>>>>>>>> stigdoessing@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
>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dagit@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 <
>>>>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dagit@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <ma...@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig
>>> Rohde
>>>>>>> Døssing
>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W.
>>>>> Call
>>>>>>> <
>>>>>>>>>>>>>>>>>>>>> bcall@apache.org
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bcall@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43
>>> skrev
>>>>>>> Ethan
>>>>>>>>>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>> hmclouro@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM,
>>> Stig
>>>>>>> Rohde
>>>>>>>>>>>>>>>>>> Døssing <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl.
>>> 19.16
>>>>>>> skrev
>>>>>>>>>>>>> Ethan
>>>>>>>>>>>>>>>>>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
>
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@gmail.com>.
Yes we can revert the two commits before merging in a new commit if we decide to include this new commit to current version.
> On Aug 19, 2019, at 2:57 PM, Stig Rohde Døssing <st...@gmail.com> wrote:
>
>> Now if we need to merge something in (2.1.0 is not released yet), we
> merge it to 2.1.x-branch. But the current pom version is 2.1.1-SNAPSHOT,
> which should really be 2.1.0-SNAPSHOT, because this commit goes into 2.1.0
> version. To fix this, we need to revert last two commits before we merge
> the new commit.
>
> Sure, but if we're merging anything to 2.1.x-branch during the release
> process, we're either expecting it to go in 2.1.1 so 2.1.1-SNAPSHOT is the
> right version, or we're cancelling the 2.1.0 vote in order to include it,
> and in that case we're reverting those two commits anyway, right? I don't
> think there's a problem with merging something in, and then reverting the
> version bump in a later commit?
>
> Den man. 19. aug. 2019 kl. 20.38 skrev Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>>:
>
>> You are right. But I was talking about the pom version.
>>
>> So if we have 2.1.x-branch and the pom version is 2.1.0-SNAPSHOT. If we
>> start release process here, i.e. run “mvn release:prepare”, it will create
>> and push two commits automatically.
>>
>> First commit: change pom version to 2.1.0; and create a v2.1.0 git tag.
>> Second commit: change pom version to 2.1.1-SNAPSHOT.
>>
>> So now in 2.1.x-branch, the pom version is 2.1.1-SNAPSHOT.
>>
>> Now if we need to merge something in (2.1.0 is not released yet), we merge
>> it to 2.1.x-branch. But the current pom version is 2.1.1-SNAPSHOT, which
>> should really be 2.1.0-SNAPSHOT, because this commit goes into 2.1.0
>> version. To fix this, we need to revert last two commits before we merge
>> the new commit.
>>
>> If we use 2.1-SNAPSHOT, we don’t need to revert.
>>
>> With that being said, I am fine with reverting if needed. It’s probably
>> safe to not change the convention.
>>
>>
>>
>>> On Aug 19, 2019, at 1:24 PM, Stig Rohde Døssing <st...@gmail.com>
>> wrote:
>>>
>>> Ok, that makes sense. I still don't understand the need for 2.1-SNAPSHOT?
>>>
>>> If we branch off 2.1.x-branch and then roll master to 2.2.0-SNAPSHOT
>>> immediately, we can merge any commits into master and mark them in Jira
>>> with fix version 2.2.0. If we then get a bugfix that needs to go in e.g.
>>> 2.1.1, we can merge it to master and cherry pick the commit back to
>>> 2.1.x-branch, and update the fix version to both 2.2.0 and 2.1.1. This is
>>> basically similar to how it worked for the 1.x-branch branches.
>>>
>>> Why do we need 2.1-SNAPSHOT?
>>>
>>> Den man. 19. aug. 2019 kl. 20.03 skrev Ethan Li <
>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>:
>>>
>>>> We don’t create 2.1.0 branch.
>>>>
>>>> I was thinking (and have been doing) about creating a 2.1.x-branch
>> before
>>>> doing any thing release related. Then we use 2.1.x-branch to release
>>>> 2.1.0, and 2.1.1, etc.
>>>>
>>>> When we create a 2.1.x-branch, we move master to 2.2.x-branch. It’s a
>>>> little different than what we did in the past. But it makes more sense
>> as
>>>> it follows semantic versioning more strictly.
>>>>
>>>>
>>>>
>>>>> On Aug 19, 2019, at 12:53 PM, Stig Rohde Døssing <
>> stigdoessing@gmail.com <ma...@gmail.com>>
>>>> wrote:
>>>>>
>>>>> I would be fine with just freezing (non-critical) merges during the
>>>>> release process. These mails are public, so it's easy for anyone to see
>>>>> whether a release is in progress.
>>>>>
>>>>> If we want to do merges while releases are going on, I think your
>>>> proposal
>>>>> of using a release branch is fine. I'm not sure I understand why we
>> need
>>>>> the 2.1-SNAPSHOT version though?
>>>>>
>>>>> Let's say we create release branch 2.1.0-branch from master. We roll
>> the
>>>>> master version to 2.1.1-SNAPSHOT (for example) after the 2.1.0 branch
>> is
>>>>> created. We then get a bug fix that should go in 2.1.0. In this case we
>>>>> should merge it to 2.1.0-branch, then merge 2.1.0-branch to master. In
>>>> Jira
>>>>> we mark it as going in 2.1.0.
>>>>>
>>>>> We then get a PR that shouldn't be included in 2.1.0. We just merge it
>> to
>>>>> master, and mark it as 2.1.1 in Jira.
>>>>>
>>>>> Finally once 2.1.0 is released, we merge 2.1.0-branch into master and
>>>>> delete 2.1.0-branch.
>>>>>
>>>>> Why is there a need to 2.1-SNAPSHOT?
>>>>>
>>>>> Den man. 19. aug. 2019 kl. 18.15 skrev Ethan Li <
>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>> <mailto:
>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>:
>>>>>
>>>>>> Many issues came up while I was preparing for 2.1.0 release. Freezing
>>>>>> merge until the release is done is not practical. So I am proposing:
>>>>>>
>>>>>> 1. Once we decide to make a release, we create a new branch based on
>>>>>> master and start release process.
>>>>>> 2. During the new process, master is still open for backwards
>>>>>> compatibility commits, including new features, bu g fixes, etc.
>>>>>> 3. Only bug fixes will be merged to the new branch and we need to
>>>> restart
>>>>>> the release process to include the bug fixes.
>>>>>> 4. To avoid too much confusion on pom versions when we merge new
>> commits
>>>>>> during the release process, we should use less concrete version. For
>>>>>> example, in 2.1.x-branch, the pom version should be 2.1-SNAPSHOT,
>>>> instead
>>>>>> of 2.1.0-SNAPSHOT.
>>>>>>
>>>>>> For example,
>>>>>>
>>>>>> Let’s say we have a new branch 2.1.x-branch, the pom version is
>>>>>> 2.1.0-SNAPSHOT. We start the release process and after running the mvn
>>>>>> release:prepare -Pxxx command, the pom version changes to
>>>> 2.1.1-SNAPSHOT,
>>>>>> and before that a git tag v2.1.0 is created. Now if there is a bug
>> fix
>>>> we
>>>>>> have to merge in, so we merge in and it’s actually merged in to
>>>>>> 2.1.1-SNAPSHOT at this point if we don’t manually revert the pom
>>>> version,
>>>>>> which can be confusing. We can avoid this problem by just using
>>>>>> 2.1-SNAPSHOT as the pom version. So it doesn’t have to change.
>>>>>>
>>>>>> Please let me know if there is any potential risk for doing this.
>>>>>>
>>>>>> Thanks
>>>>>> Ethan
>>>>>>
>>>>>>> On Aug 19, 2019, at 10:25 AM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>
>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
>>>>>> wrote:
>>>>>>>
>>>>>>> The pull request for the fix is
>>>>>> https://github.com/apache/storm/pull/3106 <https://github.com/apache/storm/pull/3106> <
>> https://github.com/apache/storm/pull/3106 <https://github.com/apache/storm/pull/3106>> <
>>>>>> https://github.com/apache/storm/pull/3106 <https://github.com/apache/storm/pull/3106> <
>> https://github.com/apache/storm/pull/3106 <https://github.com/apache/storm/pull/3106>> <
>>>> https://github.com/apache/storm/pull/3106 <https://github.com/apache/storm/pull/3106> <
>> https://github.com/apache/storm/pull/3106 <https://github.com/apache/storm/pull/3106>>>>
>>>>>>>
>>>>>>>> On Aug 19, 2019, at 10:15 AM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>
>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
>>>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>>
>>>> wrote:
>>>>>>>>
>>>>>>>> So I was preparing for a new release candidate i.e. rc3. I can build
>>>> it
>>>>>> from source without any problem. Then I set up a standalone cluster
>> and
>>>>>> submitted a WordCountTopology. The workers kept restarting because of
>>>>>>>>
>>>>>>>>
>>>>>>>> 2019-08-19 15:09:49.635 o.a.s.t.ShellBolt Thread-30 [ERROR] Halting
>>>>>> process: ShellBolt died. Command: [python, splitsentence.py],
>>>> ProcessInfo
>>>>>> pid:3756, name:split exitCode:-1, errorString:
>>>>>>>> java.lang.IllegalArgumentException: command sync is not supported
>>>>>>>> at
>>>>>>
>>>>
>> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
>>>>>> [storm-client-2.1.0.jar:2.1.0]
>>>>>>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>>>>>>>> 2019-08-19 15:09:49.635 o.a.s.e.e.ReportError Thread-30 [ERROR]
>> Error
>>>>>>>> java.lang.IllegalArgumentException: command sync is not supported
>>>>>>>> at
>>>>>>
>>>>
>> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
>>>>>> [storm-client-2.1.0.jar:2.1.0]
>>>>>>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>>>>>>>> 2019-08-19 15:09:49.636 o.a.s.t.ShellBolt Thread-28 [ERROR] Halting
>>>>>> process: ShellBolt died. Command: [python, splitsentence.py],
>>>> ProcessInfo
>>>>>> pid:3755, name:split exitCode:-1, errorString:
>>>>>>>> java.lang.IllegalArgumentException: command sync is not supported
>>>>>>>> at
>>>>>>
>>>>
>> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
>>>>>> [storm-client-2.1.0.jar:2.1.0]
>>>>>>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>>>>>>>> 2019-08-19 15:09:49.637 o.a.s.e.e.ReportError Thread-28 [ERROR]
>> Error
>>>>>>>> java.lang.IllegalArgumentException: command sync is not supported
>>>>>>>> at
>>>>>>
>>>>
>> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
>>>>>> [storm-client-2.1.0.jar:2.1.0]
>>>>>>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367>
>> <
>> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367>
>>>
>>>> <
>>>>
>> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367>
>> <
>> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367>
>>>
>>>>>
>>>>>> <
>>>>>>
>>>>
>> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367>
>> <
>> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367>
>>>
>>>> <
>>>>
>> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367>
>> <
>> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367>
>>>
>>>>>>
>>>>>> I believe we shouldn’t throw exceptions here.
>>>>>>>>
>>>>>>>> Will make a pull request to fix it.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Aug 14, 2019, at 11:11 PM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>
>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
>>>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>>
>>>> wrote:
>>>>>>>>>
>>>>>>>>> Hi Taylor,
>>>>>>>>>
>>>>>>>>> Mostly I was able to follow the doc
>>>>>>
>>>>
>> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>
>>>
>>>> <
>>>>
>> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>
>>>
>>>>>
>>>>>> <
>>>>>>
>>>>
>> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>
>>>
>>>> <
>>>>
>> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>
>>>
>>>>>> ,
>>>>>> except:
>>>>>>>>>
>>>>>>>>> For Step 1, I used the following command as suggested.
>>>>>>>>> mvn release:prepare -P dist,rat,externals,examples
>>>>>>>>> mvn release:perform -P dist,rat,externals,examples
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> For Step3, I had to run "git checkout tags/v2.1.0 -b v2.1.0” so
>> that
>>>>>> I can run “mvn package” for storm-dist/binary and storm-dist/source
>>>> based
>>>>>> on v2.1.0. Otherwise if I run “mvn package” on 2.1.x-branch, it will
>>>> fail
>>>>>> because the pom version is “2.1.x-SNAPSHOT”.
>>>>>>>>>
>>>>>>>>> Then I find packages in storm-dist/binary/final-package/target and
>>>>>> storm-dist/source/target, sign them, generate checksum and copy them
>> to
>>>> svn.
>>>>>>>>>
>>>>>>>>> I think there are something I should do. But please let me know if
>> I
>>>>>> was doing something wrong. I will also update the doc after the
>>>> release
>>>>>> is complete. Thank you very much!
>>>>>>>>>
>>>>>>>>> Ethan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On Aug 14, 2019, at 12:24 PM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>
>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
>>>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>>
>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> I am continuing for another release candidate since the pr is
>>>> merged.
>>>>>>>>>>
>>>>>>>>>>> On Aug 13, 2019, at 11:58 AM, Stig Rohde Døssing <
>>>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>> <mailto:
>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Updated https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>> <
>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>>> <
>>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>> <
>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>>>> so we don't have
>>>>>>>>>>> org.apache.storm artifacts in the DEPENDENCY-LICENSES file. It's
>>>>>> ready for
>>>>>>>>>>> review if someone wants to look at it.
>>>>>>>>>>>
>>>>>>>>>>> Den tir. 13. aug. 2019 kl. 18.21 skrev Ethan Li <
>>>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>> <mailto:
>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>> <mailto:
>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>> <mailto:
>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>>:
>>>>>>>>>>>
>>>>>>>>>>>> Thank you, Taylor. Will delete them.
>>>>>>>>>>>>
>>>>>>>>>>>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <
>> ptgoetz@gmail.com <ma...@gmail.com> <mailto:ptgoetz@gmail.com <ma...@gmail.com>>
>>>> <mailto:ptgoetz@gmail.com <ma...@gmail.com> <mailto:ptgoetz@gmail.com <ma...@gmail.com>>>
>>>>>> <mailto:ptgoetz@gmail.com <ma...@gmail.com> <mailto:ptgoetz@gmail.com <ma...@gmail.com>> <mailto:
>> ptgoetz@gmail.com <ma...@gmail.com> <mailto:ptgoetz@gmail.com <ma...@gmail.com>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Those can be safely deleted.
>>>>>>>>>>>>>
>>>>>>>>>>>>> -Taylor
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Aug 13, 2019, at 12:15 PM, Ethan Li <
>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>> <mailto:
>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
>>>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Do we need/want to clean up the release candidate from
>>>>>>>>>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>> <
>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>>> <
>>>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>> <
>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>>>> <
>>>>>>>>>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>> <
>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>>> <
>>>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>> <
>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>>>>> ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>
>>>> <
>>>>
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>
>>>>>
>>>>>> <
>>>>>>
>>>>
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>
>>>> <
>>>>
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>
>>>>>
>>>>>>>
>>>>>>>>>>>> <
>>>>>>>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>
>>>> <
>>>>
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>
>>>>>
>>>>>> <
>>>>>>
>>>>
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>
>>>> <
>>>>
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>
>>>>>
>>>>>>>>
>>>>>>>>>>>> says we do. But we have a lot of rc in
>>>>>>>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>> <
>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>>> <
>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>> <
>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>>>> <
>>>>>>>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>> <
>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>>> <
>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>> <
>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Just want to be absolutely sure about this. Thanks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Aug 13, 2019, at 10:56 AM, Ethan Li <
>>>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>> <mailto:
>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>> <mailto:
>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>> <mailto:
>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> That sounds better. It will be easier for release. Thank you
>>>> for
>>>>>>>>>>>> looking into this.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Aug 13, 2019, at 10:54 AM, Stig Rohde Døssing <
>>>>>>>>>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>> <mailto:
>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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 <
>>>>>>>>>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@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 <
>>>>>>>>>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>> <mailto:
>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>>>>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Oops, sorry that's not right. The license plugin setup was
>>>>>> disabled
>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031> <
>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031>> <
>>>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031> <
>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031>>> <
>>>>>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031> <
>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031>> <
>>>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031> <
>> https://github.com/apache/storm/pull/3031 <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 <https://github.com/apache/storm/pull/3053> <
>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>> <
>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>>> <
>>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>> <
>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>> https://github.com/apache/storm/pull/3053 <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
>> <
>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>
>> <mailto:stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>>
>>>> <mailto:stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>>>>:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> There's a script that can help you do it in
>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>> <
>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>>> <
>>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>> <
>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>> https://github.com/apache/storm/pull/3053 <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 <
>>>>>>>>>>>>>>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:
>> ethanopensource@gmail.com <ma...@gmail.com>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:
>> ethanopensource@gmail.com <ma...@gmail.com>>>
>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@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?> <
>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>> <
>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>>> <
>>>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>> <
>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>>>>
>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>
>>>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>> <
>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>>> <
>>>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>> <
>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
>> 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 <
>>>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>> <mailto:
>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>> <mailto:
>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>> <mailto:
>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@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 <
>>>>>> ptgoetz@gmail.com <ma...@gmail.com> <mailto:ptgoetz@gmail.com <ma...@gmail.com>> <mailto:
>> ptgoetz@gmail.com <ma...@gmail.com> <mailto:ptgoetz@gmail.com <ma...@gmail.com>>> <mailto:ptgoetz@gmail.com <ma...@gmail.com>
>> <mailto:ptgoetz@gmail.com <ma...@gmail.com>>
>>>> <mailto:ptgoetz@gmail.com <ma...@gmail.com> <mailto:ptgoetz@gmail.com <ma...@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 <
>>>>>>>>>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@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>
>> <
>> 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>
>>>
>>>> <
>>>>
>> 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
>>>
>>>>>
>>>>>> <
>>>>>>
>>>>
>> 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
>>>>>
>>>>>>>
>>>>>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>
>>>>
>> 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 <
>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>> ptgoetz@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 <
>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>> ethanopensource@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
>> <
>>>>>>>>>>>>>>>>>>>> stigdoessing@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
>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dagit@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 <
>>>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dagit@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <ma...@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig
>> Rohde
>>>>>> Døssing
>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W.
>>>> Call
>>>>>> <
>>>>>>>>>>>>>>>>>>>> bcall@apache.org
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bcall@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43
>> skrev
>>>>>> Ethan
>>>>>>>>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>> hmclouro@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM,
>> Stig
>>>>>> Rohde
>>>>>>>>>>>>>>>>> Døssing <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl.
>> 19.16
>>>>>> skrev
>>>>>>>>>>>> Ethan
>>>>>>>>>>>>>>>>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
Re: [DISCUSS] Next 2.x release
Posted by Stig Rohde Døssing <st...@gmail.com>.
> Now if we need to merge something in (2.1.0 is not released yet), we
merge it to 2.1.x-branch. But the current pom version is 2.1.1-SNAPSHOT,
which should really be 2.1.0-SNAPSHOT, because this commit goes into 2.1.0
version. To fix this, we need to revert last two commits before we merge
the new commit.
Sure, but if we're merging anything to 2.1.x-branch during the release
process, we're either expecting it to go in 2.1.1 so 2.1.1-SNAPSHOT is the
right version, or we're cancelling the 2.1.0 vote in order to include it,
and in that case we're reverting those two commits anyway, right? I don't
think there's a problem with merging something in, and then reverting the
version bump in a later commit?
Den man. 19. aug. 2019 kl. 20.38 skrev Ethan Li <et...@gmail.com>:
> You are right. But I was talking about the pom version.
>
> So if we have 2.1.x-branch and the pom version is 2.1.0-SNAPSHOT. If we
> start release process here, i.e. run “mvn release:prepare”, it will create
> and push two commits automatically.
>
> First commit: change pom version to 2.1.0; and create a v2.1.0 git tag.
> Second commit: change pom version to 2.1.1-SNAPSHOT.
>
> So now in 2.1.x-branch, the pom version is 2.1.1-SNAPSHOT.
>
> Now if we need to merge something in (2.1.0 is not released yet), we merge
> it to 2.1.x-branch. But the current pom version is 2.1.1-SNAPSHOT, which
> should really be 2.1.0-SNAPSHOT, because this commit goes into 2.1.0
> version. To fix this, we need to revert last two commits before we merge
> the new commit.
>
> If we use 2.1-SNAPSHOT, we don’t need to revert.
>
> With that being said, I am fine with reverting if needed. It’s probably
> safe to not change the convention.
>
>
>
> > On Aug 19, 2019, at 1:24 PM, Stig Rohde Døssing <st...@gmail.com>
> wrote:
> >
> > Ok, that makes sense. I still don't understand the need for 2.1-SNAPSHOT?
> >
> > If we branch off 2.1.x-branch and then roll master to 2.2.0-SNAPSHOT
> > immediately, we can merge any commits into master and mark them in Jira
> > with fix version 2.2.0. If we then get a bugfix that needs to go in e.g.
> > 2.1.1, we can merge it to master and cherry pick the commit back to
> > 2.1.x-branch, and update the fix version to both 2.2.0 and 2.1.1. This is
> > basically similar to how it worked for the 1.x-branch branches.
> >
> > Why do we need 2.1-SNAPSHOT?
> >
> > Den man. 19. aug. 2019 kl. 20.03 skrev Ethan Li <
> ethanopensource@gmail.com <ma...@gmail.com>>:
> >
> >> We don’t create 2.1.0 branch.
> >>
> >> I was thinking (and have been doing) about creating a 2.1.x-branch
> before
> >> doing any thing release related. Then we use 2.1.x-branch to release
> >> 2.1.0, and 2.1.1, etc.
> >>
> >> When we create a 2.1.x-branch, we move master to 2.2.x-branch. It’s a
> >> little different than what we did in the past. But it makes more sense
> as
> >> it follows semantic versioning more strictly.
> >>
> >>
> >>
> >>> On Aug 19, 2019, at 12:53 PM, Stig Rohde Døssing <
> stigdoessing@gmail.com>
> >> wrote:
> >>>
> >>> I would be fine with just freezing (non-critical) merges during the
> >>> release process. These mails are public, so it's easy for anyone to see
> >>> whether a release is in progress.
> >>>
> >>> If we want to do merges while releases are going on, I think your
> >> proposal
> >>> of using a release branch is fine. I'm not sure I understand why we
> need
> >>> the 2.1-SNAPSHOT version though?
> >>>
> >>> Let's say we create release branch 2.1.0-branch from master. We roll
> the
> >>> master version to 2.1.1-SNAPSHOT (for example) after the 2.1.0 branch
> is
> >>> created. We then get a bug fix that should go in 2.1.0. In this case we
> >>> should merge it to 2.1.0-branch, then merge 2.1.0-branch to master. In
> >> Jira
> >>> we mark it as going in 2.1.0.
> >>>
> >>> We then get a PR that shouldn't be included in 2.1.0. We just merge it
> to
> >>> master, and mark it as 2.1.1 in Jira.
> >>>
> >>> Finally once 2.1.0 is released, we merge 2.1.0-branch into master and
> >>> delete 2.1.0-branch.
> >>>
> >>> Why is there a need to 2.1-SNAPSHOT?
> >>>
> >>> Den man. 19. aug. 2019 kl. 18.15 skrev Ethan Li <
> >> ethanopensource@gmail.com <ma...@gmail.com> <mailto:
> ethanopensource@gmail.com <ma...@gmail.com>>>:
> >>>
> >>>> Many issues came up while I was preparing for 2.1.0 release. Freezing
> >>>> merge until the release is done is not practical. So I am proposing:
> >>>>
> >>>> 1. Once we decide to make a release, we create a new branch based on
> >>>> master and start release process.
> >>>> 2. During the new process, master is still open for backwards
> >>>> compatibility commits, including new features, bu g fixes, etc.
> >>>> 3. Only bug fixes will be merged to the new branch and we need to
> >> restart
> >>>> the release process to include the bug fixes.
> >>>> 4. To avoid too much confusion on pom versions when we merge new
> commits
> >>>> during the release process, we should use less concrete version. For
> >>>> example, in 2.1.x-branch, the pom version should be 2.1-SNAPSHOT,
> >> instead
> >>>> of 2.1.0-SNAPSHOT.
> >>>>
> >>>> For example,
> >>>>
> >>>> Let’s say we have a new branch 2.1.x-branch, the pom version is
> >>>> 2.1.0-SNAPSHOT. We start the release process and after running the mvn
> >>>> release:prepare -Pxxx command, the pom version changes to
> >> 2.1.1-SNAPSHOT,
> >>>> and before that a git tag v2.1.0 is created. Now if there is a bug
> fix
> >> we
> >>>> have to merge in, so we merge in and it’s actually merged in to
> >>>> 2.1.1-SNAPSHOT at this point if we don’t manually revert the pom
> >> version,
> >>>> which can be confusing. We can avoid this problem by just using
> >>>> 2.1-SNAPSHOT as the pom version. So it doesn’t have to change.
> >>>>
> >>>> Please let me know if there is any potential risk for doing this.
> >>>>
> >>>> Thanks
> >>>> Ethan
> >>>>
> >>>>> On Aug 19, 2019, at 10:25 AM, Ethan Li <ethanopensource@gmail.com
> <ma...@gmail.com>>
> >>>> wrote:
> >>>>>
> >>>>> The pull request for the fix is
> >>>> https://github.com/apache/storm/pull/3106 <
> https://github.com/apache/storm/pull/3106> <
> >>>> https://github.com/apache/storm/pull/3106 <
> https://github.com/apache/storm/pull/3106> <
> >> https://github.com/apache/storm/pull/3106 <
> https://github.com/apache/storm/pull/3106>>>
> >>>>>
> >>>>>> On Aug 19, 2019, at 10:15 AM, Ethan Li <ethanopensource@gmail.com
> <ma...@gmail.com>
> >> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
> >>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>
> >> wrote:
> >>>>>>
> >>>>>> So I was preparing for a new release candidate i.e. rc3. I can build
> >> it
> >>>> from source without any problem. Then I set up a standalone cluster
> and
> >>>> submitted a WordCountTopology. The workers kept restarting because of
> >>>>>>
> >>>>>>
> >>>>>> 2019-08-19 15:09:49.635 o.a.s.t.ShellBolt Thread-30 [ERROR] Halting
> >>>> process: ShellBolt died. Command: [python, splitsentence.py],
> >> ProcessInfo
> >>>> pid:3756, name:split exitCode:-1, errorString:
> >>>>>> java.lang.IllegalArgumentException: command sync is not supported
> >>>>>> at
> >>>>
> >>
> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
> >>>> [storm-client-2.1.0.jar:2.1.0]
> >>>>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
> >>>>>> 2019-08-19 15:09:49.635 o.a.s.e.e.ReportError Thread-30 [ERROR]
> Error
> >>>>>> java.lang.IllegalArgumentException: command sync is not supported
> >>>>>> at
> >>>>
> >>
> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
> >>>> [storm-client-2.1.0.jar:2.1.0]
> >>>>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
> >>>>>> 2019-08-19 15:09:49.636 o.a.s.t.ShellBolt Thread-28 [ERROR] Halting
> >>>> process: ShellBolt died. Command: [python, splitsentence.py],
> >> ProcessInfo
> >>>> pid:3755, name:split exitCode:-1, errorString:
> >>>>>> java.lang.IllegalArgumentException: command sync is not supported
> >>>>>> at
> >>>>
> >>
> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
> >>>> [storm-client-2.1.0.jar:2.1.0]
> >>>>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
> >>>>>> 2019-08-19 15:09:49.637 o.a.s.e.e.ReportError Thread-28 [ERROR]
> Error
> >>>>>> java.lang.IllegalArgumentException: command sync is not supported
> >>>>>> at
> >>>>
> >>
> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
> >>>> [storm-client-2.1.0.jar:2.1.0]
> >>>>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> <
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> >
> >> <
> >>
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> <
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> >
> >>>
> >>>> <
> >>>>
> >>
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> <
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> >
> >> <
> >>
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> <
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> >
> >>>>
> >>>> I believe we shouldn’t throw exceptions here.
> >>>>>>
> >>>>>> Will make a pull request to fix it.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> On Aug 14, 2019, at 11:11 PM, Ethan Li <ethanopensource@gmail.com
> <ma...@gmail.com>
> >> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
> >>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>
> >> wrote:
> >>>>>>>
> >>>>>>> Hi Taylor,
> >>>>>>>
> >>>>>>> Mostly I was able to follow the doc
> >>>>
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> >
> >> <
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> >
> >>>
> >>>> <
> >>>>
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> >
> >> <
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> >
> >>>> ,
> >>>> except:
> >>>>>>>
> >>>>>>> For Step 1, I used the following command as suggested.
> >>>>>>> mvn release:prepare -P dist,rat,externals,examples
> >>>>>>> mvn release:perform -P dist,rat,externals,examples
> >>>>>>>
> >>>>>>>
> >>>>>>> For Step3, I had to run "git checkout tags/v2.1.0 -b v2.1.0” so
> that
> >>>> I can run “mvn package” for storm-dist/binary and storm-dist/source
> >> based
> >>>> on v2.1.0. Otherwise if I run “mvn package” on 2.1.x-branch, it will
> >> fail
> >>>> because the pom version is “2.1.x-SNAPSHOT”.
> >>>>>>>
> >>>>>>> Then I find packages in storm-dist/binary/final-package/target and
> >>>> storm-dist/source/target, sign them, generate checksum and copy them
> to
> >> svn.
> >>>>>>>
> >>>>>>> I think there are something I should do. But please let me know if
> I
> >>>> was doing something wrong. I will also update the doc after the
> >> release
> >>>> is complete. Thank you very much!
> >>>>>>>
> >>>>>>> Ethan
> >>>>>>>
> >>>>>>>
> >>>>>>>> On Aug 14, 2019, at 12:24 PM, Ethan Li <ethanopensource@gmail.com
> <ma...@gmail.com>
> >> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
> >>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>
> >> wrote:
> >>>>>>>>
> >>>>>>>> I am continuing for another release candidate since the pr is
> >> merged.
> >>>>>>>>
> >>>>>>>>> On Aug 13, 2019, at 11:58 AM, Stig Rohde Døssing <
> >>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:
> stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
> >> stigdoessing@gmail.com <ma...@gmail.com> <mailto:
> stigdoessing@gmail.com <ma...@gmail.com>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> Updated https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053> <
> >> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053>> <
> >>>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053> <
> >> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053>>> so we don't have
> >>>>>>>>> org.apache.storm artifacts in the DEPENDENCY-LICENSES file. It's
> >>>> ready for
> >>>>>>>>> review if someone wants to look at it.
> >>>>>>>>>
> >>>>>>>>> Den tir. 13. aug. 2019 kl. 18.21 skrev Ethan Li <
> >>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:
> ethanopensource@gmail.com <ma...@gmail.com>> <mailto:
> >> ethanopensource@gmail.com <ma...@gmail.com> <mailto:
> ethanopensource@gmail.com <ma...@gmail.com>>>>:
> >>>>>>>>>
> >>>>>>>>>> Thank you, Taylor. Will delete them.
> >>>>>>>>>>
> >>>>>>>>>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <
> ptgoetz@gmail.com <ma...@gmail.com>
> >> <mailto:ptgoetz@gmail.com <ma...@gmail.com>>
> >>>> <mailto:ptgoetz@gmail.com <ma...@gmail.com> <mailto:
> ptgoetz@gmail.com <ma...@gmail.com>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Those can be safely deleted.
> >>>>>>>>>>>
> >>>>>>>>>>> -Taylor
> >>>>>>>>>>>
> >>>>>>>>>>>> On Aug 13, 2019, at 12:15 PM, Ethan Li <
> >> ethanopensource@gmail.com <ma...@gmail.com> <mailto:
> ethanopensource@gmail.com <ma...@gmail.com>>
> >>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Do we need/want to clean up the release candidate from
> >>>>>>>>>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm> <
> >> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm>> <
> >>>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm> <
> >> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm>>> <
> >>>>>>>>>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm> <
> >> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm>> <
> >>>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm> <
> >> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm>>>> ?
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >> <
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>>
> >>>> <
> >>>>
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >> <
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>>
> >>>>>
> >>>>>>>>>> <
> >>>>>>>>>>
> >>>>
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >> <
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>>
> >>>> <
> >>>>
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >> <
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>>
> >>>>>>
> >>>>>>>>>> says we do. But we have a lot of rc in
> >>>>>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/> <
> >> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/>> <
> >>>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/> <
> >> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/>>> <
> >>>>>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/> <
> >> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/>> <
> >>>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/> <
> >> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Just want to be absolutely sure about this. Thanks.
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On Aug 13, 2019, at 10:56 AM, Ethan Li <
> >>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:
> ethanopensource@gmail.com <ma...@gmail.com>> <mailto:
> >> ethanopensource@gmail.com <ma...@gmail.com> <mailto:
> ethanopensource@gmail.com <ma...@gmail.com>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> That sounds better. It will be easier for release. Thank you
> >> for
> >>>>>>>>>> looking into this.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Aug 13, 2019, at 10:54 AM, Stig Rohde Døssing <
> >>>>>>>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:
> stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
> >> stigdoessing@gmail.com <ma...@gmail.com> <mailto:
> stigdoessing@gmail.com <ma...@gmail.com>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> 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 <
> >>>>>>>>>> ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
> >> <mailto:ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@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 <
> >>>>>>>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:
> stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
> >> stigdoessing@gmail.com <ma...@gmail.com> <mailto:
> stigdoessing@gmail.com <ma...@gmail.com>>>>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Oops, sorry that's not right. The license plugin setup was
> >>>> disabled
> >>>>>>>>>> in
> >>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3031 <
> https://github.com/apache/storm/pull/3031> <
> >> https://github.com/apache/storm/pull/3031 <
> https://github.com/apache/storm/pull/3031>> <
> >>>> https://github.com/apache/storm/pull/3031 <
> https://github.com/apache/storm/pull/3031> <
> >> https://github.com/apache/storm/pull/3031 <
> 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 <
> https://github.com/apache/storm/pull/3053> <
> >> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053>> <
> >>>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053> <
> >> https://github.com/apache/storm/pull/3053 <
> 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
> <
> >>>>>>>>>>>>>>>> stigdoessing@gmail.com <ma...@gmail.com>
> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>
> >> <mailto:stigdoessing@gmail.com <ma...@gmail.com> <mailto:
> stigdoessing@gmail.com <ma...@gmail.com>>>>:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> There's a script that can help you do it in
> >>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053> <
> >> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053>> <
> >>>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053> <
> >> https://github.com/apache/storm/pull/3053 <
> 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 <
> >>>>>>>>>>>>>>> ethanopensource@gmail.com <mailto:
> ethanopensource@gmail.com> <mailto:ethanopensource@gmail.com <mailto:
> ethanopensource@gmail.com>>
> >> <mailto:ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@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?> <
> >> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>> <
> >>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
> >> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>>>
> >>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>
> >>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
> >> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>> <
> >>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
> >> 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 <
> >>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:
> ethanopensource@gmail.com <ma...@gmail.com>> <mailto:
> >> ethanopensource@gmail.com <ma...@gmail.com> <mailto:
> ethanopensource@gmail.com <ma...@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 <
> >>>> ptgoetz@gmail.com <ma...@gmail.com> <mailto:
> ptgoetz@gmail.com <ma...@gmail.com>> <mailto:ptgoetz@gmail.com
> <ma...@gmail.com>
> >> <mailto:ptgoetz@gmail.com <ma...@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 <
> >>>>>>>>>> ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
> >> <mailto:ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@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
> >
> >> <
> >>
> 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
> >
> >>>
> >>>> <
> >>>>
> >>
> 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
> >>>
> >>>>>
> >>>>>>>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>
> >>>>
> >>
> 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 <
> >>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>> ptgoetz@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 <
> >>>>>>>>>>>>>>>>>> stigdoessing@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 <
> >>>>>>>>>>>>>>>>>> ethanopensource@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
> <
> >>>>>>>>>>>>>>>>>> stigdoessing@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
> <
> >>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>> dagit@apache.org
> >>>>>>>>>>>>>>>>>> <mailto:
> >>>>>>>>>>>>>>>>>>>>>>>>>>> dagit@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 <
> >>>>>>>>>> dagit@apache.org
> >>>>>>>>>>>>>>>>>> <mailto:
> >>>>>>>>>>>>>>>>>>>>>>>>>>> dagit@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>> dagit@apache.org
> >>>>>>>>>>>>>>>>>>>>>>>>>>> <ma...@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig
> Rohde
> >>>> Døssing
> >>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W.
> >> Call
> >>>> <
> >>>>>>>>>>>>>>>>>> bcall@apache.org
> >>>>>>>>>>>>>>>>>>>>>>>>>>> <mailto:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bcall@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43
> skrev
> >>>> Ethan
> >>>>>>>>>> Li <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>> hmclouro@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM,
> Stig
> >>>> Rohde
> >>>>>>>>>>>>>>> Døssing <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl.
> 19.16
> >>>> skrev
> >>>>>>>>>> Ethan
> >>>>>>>>>>>>>>>>>> Li <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
>
>
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@gmail.com>.
You are right. But I was talking about the pom version.
So if we have 2.1.x-branch and the pom version is 2.1.0-SNAPSHOT. If we start release process here, i.e. run “mvn release:prepare”, it will create and push two commits automatically.
First commit: change pom version to 2.1.0; and create a v2.1.0 git tag.
Second commit: change pom version to 2.1.1-SNAPSHOT.
So now in 2.1.x-branch, the pom version is 2.1.1-SNAPSHOT.
Now if we need to merge something in (2.1.0 is not released yet), we merge it to 2.1.x-branch. But the current pom version is 2.1.1-SNAPSHOT, which should really be 2.1.0-SNAPSHOT, because this commit goes into 2.1.0 version. To fix this, we need to revert last two commits before we merge the new commit.
If we use 2.1-SNAPSHOT, we don’t need to revert.
With that being said, I am fine with reverting if needed. It’s probably safe to not change the convention.
> On Aug 19, 2019, at 1:24 PM, Stig Rohde Døssing <st...@gmail.com> wrote:
>
> Ok, that makes sense. I still don't understand the need for 2.1-SNAPSHOT?
>
> If we branch off 2.1.x-branch and then roll master to 2.2.0-SNAPSHOT
> immediately, we can merge any commits into master and mark them in Jira
> with fix version 2.2.0. If we then get a bugfix that needs to go in e.g.
> 2.1.1, we can merge it to master and cherry pick the commit back to
> 2.1.x-branch, and update the fix version to both 2.2.0 and 2.1.1. This is
> basically similar to how it worked for the 1.x-branch branches.
>
> Why do we need 2.1-SNAPSHOT?
>
> Den man. 19. aug. 2019 kl. 20.03 skrev Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>>:
>
>> We don’t create 2.1.0 branch.
>>
>> I was thinking (and have been doing) about creating a 2.1.x-branch before
>> doing any thing release related. Then we use 2.1.x-branch to release
>> 2.1.0, and 2.1.1, etc.
>>
>> When we create a 2.1.x-branch, we move master to 2.2.x-branch. It’s a
>> little different than what we did in the past. But it makes more sense as
>> it follows semantic versioning more strictly.
>>
>>
>>
>>> On Aug 19, 2019, at 12:53 PM, Stig Rohde Døssing <st...@gmail.com>
>> wrote:
>>>
>>> I would be fine with just freezing (non-critical) merges during the
>>> release process. These mails are public, so it's easy for anyone to see
>>> whether a release is in progress.
>>>
>>> If we want to do merges while releases are going on, I think your
>> proposal
>>> of using a release branch is fine. I'm not sure I understand why we need
>>> the 2.1-SNAPSHOT version though?
>>>
>>> Let's say we create release branch 2.1.0-branch from master. We roll the
>>> master version to 2.1.1-SNAPSHOT (for example) after the 2.1.0 branch is
>>> created. We then get a bug fix that should go in 2.1.0. In this case we
>>> should merge it to 2.1.0-branch, then merge 2.1.0-branch to master. In
>> Jira
>>> we mark it as going in 2.1.0.
>>>
>>> We then get a PR that shouldn't be included in 2.1.0. We just merge it to
>>> master, and mark it as 2.1.1 in Jira.
>>>
>>> Finally once 2.1.0 is released, we merge 2.1.0-branch into master and
>>> delete 2.1.0-branch.
>>>
>>> Why is there a need to 2.1-SNAPSHOT?
>>>
>>> Den man. 19. aug. 2019 kl. 18.15 skrev Ethan Li <
>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>:
>>>
>>>> Many issues came up while I was preparing for 2.1.0 release. Freezing
>>>> merge until the release is done is not practical. So I am proposing:
>>>>
>>>> 1. Once we decide to make a release, we create a new branch based on
>>>> master and start release process.
>>>> 2. During the new process, master is still open for backwards
>>>> compatibility commits, including new features, bu g fixes, etc.
>>>> 3. Only bug fixes will be merged to the new branch and we need to
>> restart
>>>> the release process to include the bug fixes.
>>>> 4. To avoid too much confusion on pom versions when we merge new commits
>>>> during the release process, we should use less concrete version. For
>>>> example, in 2.1.x-branch, the pom version should be 2.1-SNAPSHOT,
>> instead
>>>> of 2.1.0-SNAPSHOT.
>>>>
>>>> For example,
>>>>
>>>> Let’s say we have a new branch 2.1.x-branch, the pom version is
>>>> 2.1.0-SNAPSHOT. We start the release process and after running the mvn
>>>> release:prepare -Pxxx command, the pom version changes to
>> 2.1.1-SNAPSHOT,
>>>> and before that a git tag v2.1.0 is created. Now if there is a bug fix
>> we
>>>> have to merge in, so we merge in and it’s actually merged in to
>>>> 2.1.1-SNAPSHOT at this point if we don’t manually revert the pom
>> version,
>>>> which can be confusing. We can avoid this problem by just using
>>>> 2.1-SNAPSHOT as the pom version. So it doesn’t have to change.
>>>>
>>>> Please let me know if there is any potential risk for doing this.
>>>>
>>>> Thanks
>>>> Ethan
>>>>
>>>>> On Aug 19, 2019, at 10:25 AM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>>
>>>> wrote:
>>>>>
>>>>> The pull request for the fix is
>>>> https://github.com/apache/storm/pull/3106 <https://github.com/apache/storm/pull/3106> <
>>>> https://github.com/apache/storm/pull/3106 <https://github.com/apache/storm/pull/3106> <
>> https://github.com/apache/storm/pull/3106 <https://github.com/apache/storm/pull/3106>>>
>>>>>
>>>>>> On Aug 19, 2019, at 10:15 AM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>
>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>
>> wrote:
>>>>>>
>>>>>> So I was preparing for a new release candidate i.e. rc3. I can build
>> it
>>>> from source without any problem. Then I set up a standalone cluster and
>>>> submitted a WordCountTopology. The workers kept restarting because of
>>>>>>
>>>>>>
>>>>>> 2019-08-19 15:09:49.635 o.a.s.t.ShellBolt Thread-30 [ERROR] Halting
>>>> process: ShellBolt died. Command: [python, splitsentence.py],
>> ProcessInfo
>>>> pid:3756, name:split exitCode:-1, errorString:
>>>>>> java.lang.IllegalArgumentException: command sync is not supported
>>>>>> at
>>>>
>> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
>>>> [storm-client-2.1.0.jar:2.1.0]
>>>>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>>>>>> 2019-08-19 15:09:49.635 o.a.s.e.e.ReportError Thread-30 [ERROR] Error
>>>>>> java.lang.IllegalArgumentException: command sync is not supported
>>>>>> at
>>>>
>> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
>>>> [storm-client-2.1.0.jar:2.1.0]
>>>>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>>>>>> 2019-08-19 15:09:49.636 o.a.s.t.ShellBolt Thread-28 [ERROR] Halting
>>>> process: ShellBolt died. Command: [python, splitsentence.py],
>> ProcessInfo
>>>> pid:3755, name:split exitCode:-1, errorString:
>>>>>> java.lang.IllegalArgumentException: command sync is not supported
>>>>>> at
>>>>
>> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
>>>> [storm-client-2.1.0.jar:2.1.0]
>>>>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>>>>>> 2019-08-19 15:09:49.637 o.a.s.e.e.ReportError Thread-28 [ERROR] Error
>>>>>> java.lang.IllegalArgumentException: command sync is not supported
>>>>>> at
>>>>
>> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
>>>> [storm-client-2.1.0.jar:2.1.0]
>>>>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367>
>> <
>> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367>
>>>
>>>> <
>>>>
>> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367>
>> <
>> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367>
>>>>
>>>> I believe we shouldn’t throw exceptions here.
>>>>>>
>>>>>> Will make a pull request to fix it.
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Aug 14, 2019, at 11:11 PM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>
>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>
>> wrote:
>>>>>>>
>>>>>>> Hi Taylor,
>>>>>>>
>>>>>>> Mostly I was able to follow the doc
>>>>
>> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>
>>>
>>>> <
>>>>
>> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>
>>>> ,
>>>> except:
>>>>>>>
>>>>>>> For Step 1, I used the following command as suggested.
>>>>>>> mvn release:prepare -P dist,rat,externals,examples
>>>>>>> mvn release:perform -P dist,rat,externals,examples
>>>>>>>
>>>>>>>
>>>>>>> For Step3, I had to run "git checkout tags/v2.1.0 -b v2.1.0” so that
>>>> I can run “mvn package” for storm-dist/binary and storm-dist/source
>> based
>>>> on v2.1.0. Otherwise if I run “mvn package” on 2.1.x-branch, it will
>> fail
>>>> because the pom version is “2.1.x-SNAPSHOT”.
>>>>>>>
>>>>>>> Then I find packages in storm-dist/binary/final-package/target and
>>>> storm-dist/source/target, sign them, generate checksum and copy them to
>> svn.
>>>>>>>
>>>>>>> I think there are something I should do. But please let me know if I
>>>> was doing something wrong. I will also update the doc after the
>> release
>>>> is complete. Thank you very much!
>>>>>>>
>>>>>>> Ethan
>>>>>>>
>>>>>>>
>>>>>>>> On Aug 14, 2019, at 12:24 PM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>
>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>
>> wrote:
>>>>>>>>
>>>>>>>> I am continuing for another release candidate since the pr is
>> merged.
>>>>>>>>
>>>>>>>>> On Aug 13, 2019, at 11:58 AM, Stig Rohde Døssing <
>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>>> wrote:
>>>>>>>>>
>>>>>>>>> Updated https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>> <
>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>>> so we don't have
>>>>>>>>> org.apache.storm artifacts in the DEPENDENCY-LICENSES file. It's
>>>> ready for
>>>>>>>>> review if someone wants to look at it.
>>>>>>>>>
>>>>>>>>> Den tir. 13. aug. 2019 kl. 18.21 skrev Ethan Li <
>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>> <mailto:
>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>:
>>>>>>>>>
>>>>>>>>>> Thank you, Taylor. Will delete them.
>>>>>>>>>>
>>>>>>>>>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <ptgoetz@gmail.com <ma...@gmail.com>
>> <mailto:ptgoetz@gmail.com <ma...@gmail.com>>
>>>> <mailto:ptgoetz@gmail.com <ma...@gmail.com> <mailto:ptgoetz@gmail.com <ma...@gmail.com>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Those can be safely deleted.
>>>>>>>>>>>
>>>>>>>>>>> -Taylor
>>>>>>>>>>>
>>>>>>>>>>>> On Aug 13, 2019, at 12:15 PM, Ethan Li <
>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>>>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Do we need/want to clean up the release candidate from
>>>>>>>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>> <
>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>>> <
>>>>>>>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>> <
>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>>>> ?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>
>>>> <
>>>>
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>
>>>>>
>>>>>>>>>> <
>>>>>>>>>>
>>>>
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>
>>>> <
>>>>
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>
>>>>>>
>>>>>>>>>> says we do. But we have a lot of rc in
>>>>>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>> <
>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>>> <
>>>>>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>> <
>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Just want to be absolutely sure about this. Thanks.
>>>>>>>>>>>>
>>>>>>>>>>>>> On Aug 13, 2019, at 10:56 AM, Ethan Li <
>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>> <mailto:
>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>>
>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> That sounds better. It will be easier for release. Thank you
>> for
>>>>>>>>>> looking into this.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Aug 13, 2019, at 10:54 AM, Stig Rohde Døssing <
>>>>>>>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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 <
>>>>>>>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@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 <
>>>>>>>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>> <mailto:
>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>>>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Oops, sorry that's not right. The license plugin setup was
>>>> disabled
>>>>>>>>>> in
>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031> <
>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031>> <
>>>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031> <
>> https://github.com/apache/storm/pull/3031 <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 <https://github.com/apache/storm/pull/3053> <
>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>> <
>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>> https://github.com/apache/storm/pull/3053 <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 <
>>>>>>>>>>>>>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>
>> <mailto:stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>>>:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> There's a script that can help you do it in
>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>> <
>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>> https://github.com/apache/storm/pull/3053 <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 <
>>>>>>>>>>>>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@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?> <
>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>> <
>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>>>
>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>
>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>> <
>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
>> 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 <
>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>> <mailto:
>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@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 <
>>>> ptgoetz@gmail.com <ma...@gmail.com> <mailto:ptgoetz@gmail.com <ma...@gmail.com>> <mailto:ptgoetz@gmail.com <ma...@gmail.com>
>> <mailto:ptgoetz@gmail.com <ma...@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 <
>>>>>>>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>
>> <mailto:ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@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>
>> <
>> 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>
>>>
>>>> <
>>>>
>> 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
>>>
>>>>>
>>>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>
>>>>
>> 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 <
>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>> ptgoetz@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 <
>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>>>> dagit@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 <
>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>>>> dagit@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 <
>>>>>>>>>>>>>>>>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>>>>>>>>>>>>>> <ma...@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 <
>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde
>>>> Døssing
>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W.
>> Call
>>>> <
>>>>>>>>>>>>>>>>>> bcall@apache.org
>>>>>>>>>>>>>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bcall@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev
>>>> Ethan
>>>>>>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>> hmclouro@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig
>>>> Rohde
>>>>>>>>>>>>>>> Døssing <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16
>>>> skrev
>>>>>>>>>> Ethan
>>>>>>>>>>>>>>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
Re: [DISCUSS] Next 2.x release
Posted by Stig Rohde Døssing <st...@gmail.com>.
Ok, that makes sense. I still don't understand the need for 2.1-SNAPSHOT?
If we branch off 2.1.x-branch and then roll master to 2.2.0-SNAPSHOT
immediately, we can merge any commits into master and mark them in Jira
with fix version 2.2.0. If we then get a bugfix that needs to go in e.g.
2.1.1, we can merge it to master and cherry pick the commit back to
2.1.x-branch, and update the fix version to both 2.2.0 and 2.1.1. This is
basically similar to how it worked for the 1.x-branch branches.
Why do we need 2.1-SNAPSHOT?
Den man. 19. aug. 2019 kl. 20.03 skrev Ethan Li <et...@gmail.com>:
> We don’t create 2.1.0 branch.
>
> I was thinking (and have been doing) about creating a 2.1.x-branch before
> doing any thing release related. Then we use 2.1.x-branch to release
> 2.1.0, and 2.1.1, etc.
>
> When we create a 2.1.x-branch, we move master to 2.2.x-branch. It’s a
> little different than what we did in the past. But it makes more sense as
> it follows semantic versioning more strictly.
>
>
>
> > On Aug 19, 2019, at 12:53 PM, Stig Rohde Døssing <st...@gmail.com>
> wrote:
> >
> > I would be fine with just freezing (non-critical) merges during the
> > release process. These mails are public, so it's easy for anyone to see
> > whether a release is in progress.
> >
> > If we want to do merges while releases are going on, I think your
> proposal
> > of using a release branch is fine. I'm not sure I understand why we need
> > the 2.1-SNAPSHOT version though?
> >
> > Let's say we create release branch 2.1.0-branch from master. We roll the
> > master version to 2.1.1-SNAPSHOT (for example) after the 2.1.0 branch is
> > created. We then get a bug fix that should go in 2.1.0. In this case we
> > should merge it to 2.1.0-branch, then merge 2.1.0-branch to master. In
> Jira
> > we mark it as going in 2.1.0.
> >
> > We then get a PR that shouldn't be included in 2.1.0. We just merge it to
> > master, and mark it as 2.1.1 in Jira.
> >
> > Finally once 2.1.0 is released, we merge 2.1.0-branch into master and
> > delete 2.1.0-branch.
> >
> > Why is there a need to 2.1-SNAPSHOT?
> >
> > Den man. 19. aug. 2019 kl. 18.15 skrev Ethan Li <
> ethanopensource@gmail.com <ma...@gmail.com>>:
> >
> >> Many issues came up while I was preparing for 2.1.0 release. Freezing
> >> merge until the release is done is not practical. So I am proposing:
> >>
> >> 1. Once we decide to make a release, we create a new branch based on
> >> master and start release process.
> >> 2. During the new process, master is still open for backwards
> >> compatibility commits, including new features, bu g fixes, etc.
> >> 3. Only bug fixes will be merged to the new branch and we need to
> restart
> >> the release process to include the bug fixes.
> >> 4. To avoid too much confusion on pom versions when we merge new commits
> >> during the release process, we should use less concrete version. For
> >> example, in 2.1.x-branch, the pom version should be 2.1-SNAPSHOT,
> instead
> >> of 2.1.0-SNAPSHOT.
> >>
> >> For example,
> >>
> >> Let’s say we have a new branch 2.1.x-branch, the pom version is
> >> 2.1.0-SNAPSHOT. We start the release process and after running the mvn
> >> release:prepare -Pxxx command, the pom version changes to
> 2.1.1-SNAPSHOT,
> >> and before that a git tag v2.1.0 is created. Now if there is a bug fix
> we
> >> have to merge in, so we merge in and it’s actually merged in to
> >> 2.1.1-SNAPSHOT at this point if we don’t manually revert the pom
> version,
> >> which can be confusing. We can avoid this problem by just using
> >> 2.1-SNAPSHOT as the pom version. So it doesn’t have to change.
> >>
> >> Please let me know if there is any potential risk for doing this.
> >>
> >> Thanks
> >> Ethan
> >>
> >>> On Aug 19, 2019, at 10:25 AM, Ethan Li <et...@gmail.com>
> >> wrote:
> >>>
> >>> The pull request for the fix is
> >> https://github.com/apache/storm/pull/3106 <
> >> https://github.com/apache/storm/pull/3106 <
> https://github.com/apache/storm/pull/3106>>
> >>>
> >>>> On Aug 19, 2019, at 10:15 AM, Ethan Li <ethanopensource@gmail.com
> <ma...@gmail.com>
> >> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
> wrote:
> >>>>
> >>>> So I was preparing for a new release candidate i.e. rc3. I can build
> it
> >> from source without any problem. Then I set up a standalone cluster and
> >> submitted a WordCountTopology. The workers kept restarting because of
> >>>>
> >>>>
> >>>> 2019-08-19 15:09:49.635 o.a.s.t.ShellBolt Thread-30 [ERROR] Halting
> >> process: ShellBolt died. Command: [python, splitsentence.py],
> ProcessInfo
> >> pid:3756, name:split exitCode:-1, errorString:
> >>>> java.lang.IllegalArgumentException: command sync is not supported
> >>>> at
> >>
> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
> >> [storm-client-2.1.0.jar:2.1.0]
> >>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
> >>>> 2019-08-19 15:09:49.635 o.a.s.e.e.ReportError Thread-30 [ERROR] Error
> >>>> java.lang.IllegalArgumentException: command sync is not supported
> >>>> at
> >>
> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
> >> [storm-client-2.1.0.jar:2.1.0]
> >>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
> >>>> 2019-08-19 15:09:49.636 o.a.s.t.ShellBolt Thread-28 [ERROR] Halting
> >> process: ShellBolt died. Command: [python, splitsentence.py],
> ProcessInfo
> >> pid:3755, name:split exitCode:-1, errorString:
> >>>> java.lang.IllegalArgumentException: command sync is not supported
> >>>> at
> >>
> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
> >> [storm-client-2.1.0.jar:2.1.0]
> >>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
> >>>> 2019-08-19 15:09:49.637 o.a.s.e.e.ReportError Thread-28 [ERROR] Error
> >>>> java.lang.IllegalArgumentException: command sync is not supported
> >>>> at
> >>
> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
> >> [storm-client-2.1.0.jar:2.1.0]
> >>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> <
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> >
> >> <
> >>
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> <
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> >>
> >> I believe we shouldn’t throw exceptions here.
> >>>>
> >>>> Will make a pull request to fix it.
> >>>>
> >>>>
> >>>>
> >>>>> On Aug 14, 2019, at 11:11 PM, Ethan Li <ethanopensource@gmail.com
> <ma...@gmail.com>
> >> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
> wrote:
> >>>>>
> >>>>> Hi Taylor,
> >>>>>
> >>>>> Mostly I was able to follow the doc
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> >
> >> <
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> >>,
> >> except:
> >>>>>
> >>>>> For Step 1, I used the following command as suggested.
> >>>>> mvn release:prepare -P dist,rat,externals,examples
> >>>>> mvn release:perform -P dist,rat,externals,examples
> >>>>>
> >>>>>
> >>>>> For Step3, I had to run "git checkout tags/v2.1.0 -b v2.1.0” so that
> >> I can run “mvn package” for storm-dist/binary and storm-dist/source
> based
> >> on v2.1.0. Otherwise if I run “mvn package” on 2.1.x-branch, it will
> fail
> >> because the pom version is “2.1.x-SNAPSHOT”.
> >>>>>
> >>>>> Then I find packages in storm-dist/binary/final-package/target and
> >> storm-dist/source/target, sign them, generate checksum and copy them to
> svn.
> >>>>>
> >>>>> I think there are something I should do. But please let me know if I
> >> was doing something wrong. I will also update the doc after the
> release
> >> is complete. Thank you very much!
> >>>>>
> >>>>> Ethan
> >>>>>
> >>>>>
> >>>>>> On Aug 14, 2019, at 12:24 PM, Ethan Li <ethanopensource@gmail.com
> <ma...@gmail.com>
> >> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
> wrote:
> >>>>>>
> >>>>>> I am continuing for another release candidate since the pr is
> merged.
> >>>>>>
> >>>>>>> On Aug 13, 2019, at 11:58 AM, Stig Rohde Døssing <
> >> stigdoessing@gmail.com <ma...@gmail.com> <mailto:
> stigdoessing@gmail.com <ma...@gmail.com>>> wrote:
> >>>>>>>
> >>>>>>> Updated https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053> <
> >> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053>> so we don't have
> >>>>>>> org.apache.storm artifacts in the DEPENDENCY-LICENSES file. It's
> >> ready for
> >>>>>>> review if someone wants to look at it.
> >>>>>>>
> >>>>>>> Den tir. 13. aug. 2019 kl. 18.21 skrev Ethan Li <
> >> ethanopensource@gmail.com <ma...@gmail.com> <mailto:
> ethanopensource@gmail.com <ma...@gmail.com>>>:
> >>>>>>>
> >>>>>>>> Thank you, Taylor. Will delete them.
> >>>>>>>>
> >>>>>>>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <ptgoetz@gmail.com
> <ma...@gmail.com>
> >> <mailto:ptgoetz@gmail.com <ma...@gmail.com>>> wrote:
> >>>>>>>>>
> >>>>>>>>> Those can be safely deleted.
> >>>>>>>>>
> >>>>>>>>> -Taylor
> >>>>>>>>>
> >>>>>>>>>> On Aug 13, 2019, at 12:15 PM, Ethan Li <
> ethanopensource@gmail.com <ma...@gmail.com>
> >> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Do we need/want to clean up the release candidate from
> >>>>>>>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm> <
> >> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm>> <
> >>>>>>>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm> <
> >> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm>>> ?
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >> <
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>>
> >>>>>>>> <
> >>>>>>>>
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >> <
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>>>
> >>>>>>>> says we do. But we have a lot of rc in
> >>>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/> <
> >> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/>> <
> >>>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/> <
> >> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/>>>
> >>>>>>>>>>
> >>>>>>>>>> Just want to be absolutely sure about this. Thanks.
> >>>>>>>>>>
> >>>>>>>>>>> On Aug 13, 2019, at 10:56 AM, Ethan Li <
> >> ethanopensource@gmail.com <ma...@gmail.com> <mailto:
> ethanopensource@gmail.com <ma...@gmail.com>>>
> >>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> That sounds better. It will be easier for release. Thank you
> for
> >>>>>>>> looking into this.
> >>>>>>>>>>>
> >>>>>>>>>>>> On Aug 13, 2019, at 10:54 AM, Stig Rohde Døssing <
> >>>>>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:
> stigdoessing@gmail.com <ma...@gmail.com>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> 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 <
> >>>>>>>> ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@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 <
> >>>>>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:
> stigdoessing@gmail.com <ma...@gmail.com>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Oops, sorry that's not right. The license plugin setup was
> >> disabled
> >>>>>>>> in
> >>>>>>>>>>>>>> https://github.com/apache/storm/pull/3031 <
> https://github.com/apache/storm/pull/3031> <
> >> https://github.com/apache/storm/pull/3031 <
> 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 <
> https://github.com/apache/storm/pull/3053> <
> >> https://github.com/apache/storm/pull/3053 <
> 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 <
> >>>>>>>>>>>>>> stigdoessing@gmail.com <ma...@gmail.com>
> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>>:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> There's a script that can help you do it in
> >>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053> <
> >> https://github.com/apache/storm/pull/3053 <
> 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 <
> >>>>>>>>>>>>> ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@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?> <
> >> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>>
> >>>>>>>> <
> >>>>>>>>>>>>>>>>
> >> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
> >> 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 <
> >> ethanopensource@gmail.com <ma...@gmail.com> <mailto:
> ethanopensource@gmail.com <ma...@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 <
> >> ptgoetz@gmail.com <ma...@gmail.com> <mailto:ptgoetz@gmail.com
> <ma...@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 <
> >>>>>>>> ethanopensource@gmail.com <ma...@gmail.com>
> <mailto:ethanopensource@gmail.com <ma...@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
> >
> >> <
> >>
> 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
> >
> >>>
> >>>>>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>
> >>
> 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 <
> >>>>>>>> ethanopensource@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 <
> >>>>>>>> ptgoetz@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 <
> >>>>>>>>>>>>>>>> stigdoessing@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 <
> >>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>> stigdoessing@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 <
> >>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>> dagit@apache.org
> >>>>>>>>>>>>>>>> <mailto:
> >>>>>>>>>>>>>>>>>>>>>>>>> dagit@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 <
> >>>>>>>> dagit@apache.org
> >>>>>>>>>>>>>>>> <mailto:
> >>>>>>>>>>>>>>>>>>>>>>>>> dagit@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 <
> >>>>>>>>>>>>>>>>>>>>>>> dagit@apache.org
> >>>>>>>>>>>>>>>>>>>>>>>>> <ma...@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 <
> >>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde
> >> Døssing
> >>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W.
> Call
> >> <
> >>>>>>>>>>>>>>>> bcall@apache.org
> >>>>>>>>>>>>>>>>>>>>>>>>> <mailto:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bcall@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev
> >> Ethan
> >>>>>>>> Li <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>>>>>>>>> hmclouro@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig
> >> Rohde
> >>>>>>>>>>>>> Døssing <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16
> >> skrev
> >>>>>>>> Ethan
> >>>>>>>>>>>>>>>> Li <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
>
>
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@gmail.com>.
We don’t create 2.1.0 branch.
I was thinking (and have been doing) about creating a 2.1.x-branch before doing any thing release related. Then we use 2.1.x-branch to release 2.1.0, and 2.1.1, etc.
When we create a 2.1.x-branch, we move master to 2.2.x-branch. It’s a little different than what we did in the past. But it makes more sense as it follows semantic versioning more strictly.
> On Aug 19, 2019, at 12:53 PM, Stig Rohde Døssing <st...@gmail.com> wrote:
>
> I would be fine with just freezing (non-critical) merges during the
> release process. These mails are public, so it's easy for anyone to see
> whether a release is in progress.
>
> If we want to do merges while releases are going on, I think your proposal
> of using a release branch is fine. I'm not sure I understand why we need
> the 2.1-SNAPSHOT version though?
>
> Let's say we create release branch 2.1.0-branch from master. We roll the
> master version to 2.1.1-SNAPSHOT (for example) after the 2.1.0 branch is
> created. We then get a bug fix that should go in 2.1.0. In this case we
> should merge it to 2.1.0-branch, then merge 2.1.0-branch to master. In Jira
> we mark it as going in 2.1.0.
>
> We then get a PR that shouldn't be included in 2.1.0. We just merge it to
> master, and mark it as 2.1.1 in Jira.
>
> Finally once 2.1.0 is released, we merge 2.1.0-branch into master and
> delete 2.1.0-branch.
>
> Why is there a need to 2.1-SNAPSHOT?
>
> Den man. 19. aug. 2019 kl. 18.15 skrev Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>>:
>
>> Many issues came up while I was preparing for 2.1.0 release. Freezing
>> merge until the release is done is not practical. So I am proposing:
>>
>> 1. Once we decide to make a release, we create a new branch based on
>> master and start release process.
>> 2. During the new process, master is still open for backwards
>> compatibility commits, including new features, bu g fixes, etc.
>> 3. Only bug fixes will be merged to the new branch and we need to restart
>> the release process to include the bug fixes.
>> 4. To avoid too much confusion on pom versions when we merge new commits
>> during the release process, we should use less concrete version. For
>> example, in 2.1.x-branch, the pom version should be 2.1-SNAPSHOT, instead
>> of 2.1.0-SNAPSHOT.
>>
>> For example,
>>
>> Let’s say we have a new branch 2.1.x-branch, the pom version is
>> 2.1.0-SNAPSHOT. We start the release process and after running the mvn
>> release:prepare -Pxxx command, the pom version changes to 2.1.1-SNAPSHOT,
>> and before that a git tag v2.1.0 is created. Now if there is a bug fix we
>> have to merge in, so we merge in and it’s actually merged in to
>> 2.1.1-SNAPSHOT at this point if we don’t manually revert the pom version,
>> which can be confusing. We can avoid this problem by just using
>> 2.1-SNAPSHOT as the pom version. So it doesn’t have to change.
>>
>> Please let me know if there is any potential risk for doing this.
>>
>> Thanks
>> Ethan
>>
>>> On Aug 19, 2019, at 10:25 AM, Ethan Li <et...@gmail.com>
>> wrote:
>>>
>>> The pull request for the fix is
>> https://github.com/apache/storm/pull/3106 <
>> https://github.com/apache/storm/pull/3106 <https://github.com/apache/storm/pull/3106>>
>>>
>>>> On Aug 19, 2019, at 10:15 AM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>
>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>> wrote:
>>>>
>>>> So I was preparing for a new release candidate i.e. rc3. I can build it
>> from source without any problem. Then I set up a standalone cluster and
>> submitted a WordCountTopology. The workers kept restarting because of
>>>>
>>>>
>>>> 2019-08-19 15:09:49.635 o.a.s.t.ShellBolt Thread-30 [ERROR] Halting
>> process: ShellBolt died. Command: [python, splitsentence.py], ProcessInfo
>> pid:3756, name:split exitCode:-1, errorString:
>>>> java.lang.IllegalArgumentException: command sync is not supported
>>>> at
>> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
>> [storm-client-2.1.0.jar:2.1.0]
>>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>>>> 2019-08-19 15:09:49.635 o.a.s.e.e.ReportError Thread-30 [ERROR] Error
>>>> java.lang.IllegalArgumentException: command sync is not supported
>>>> at
>> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
>> [storm-client-2.1.0.jar:2.1.0]
>>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>>>> 2019-08-19 15:09:49.636 o.a.s.t.ShellBolt Thread-28 [ERROR] Halting
>> process: ShellBolt died. Command: [python, splitsentence.py], ProcessInfo
>> pid:3755, name:split exitCode:-1, errorString:
>>>> java.lang.IllegalArgumentException: command sync is not supported
>>>> at
>> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
>> [storm-client-2.1.0.jar:2.1.0]
>>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>>>> 2019-08-19 15:09:49.637 o.a.s.e.e.ReportError Thread-28 [ERROR] Error
>>>> java.lang.IllegalArgumentException: command sync is not supported
>>>> at
>> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
>> [storm-client-2.1.0.jar:2.1.0]
>>>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>>>>
>>>>
>>>>
>>>>
>> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367>
>> <
>> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367>>
>> I believe we shouldn’t throw exceptions here.
>>>>
>>>> Will make a pull request to fix it.
>>>>
>>>>
>>>>
>>>>> On Aug 14, 2019, at 11:11 PM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>
>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>> wrote:
>>>>>
>>>>> Hi Taylor,
>>>>>
>>>>> Mostly I was able to follow the doc
>> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>>,
>> except:
>>>>>
>>>>> For Step 1, I used the following command as suggested.
>>>>> mvn release:prepare -P dist,rat,externals,examples
>>>>> mvn release:perform -P dist,rat,externals,examples
>>>>>
>>>>>
>>>>> For Step3, I had to run "git checkout tags/v2.1.0 -b v2.1.0” so that
>> I can run “mvn package” for storm-dist/binary and storm-dist/source based
>> on v2.1.0. Otherwise if I run “mvn package” on 2.1.x-branch, it will fail
>> because the pom version is “2.1.x-SNAPSHOT”.
>>>>>
>>>>> Then I find packages in storm-dist/binary/final-package/target and
>> storm-dist/source/target, sign them, generate checksum and copy them to svn.
>>>>>
>>>>> I think there are something I should do. But please let me know if I
>> was doing something wrong. I will also update the doc after the release
>> is complete. Thank you very much!
>>>>>
>>>>> Ethan
>>>>>
>>>>>
>>>>>> On Aug 14, 2019, at 12:24 PM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>
>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>> wrote:
>>>>>>
>>>>>> I am continuing for another release candidate since the pr is merged.
>>>>>>
>>>>>>> On Aug 13, 2019, at 11:58 AM, Stig Rohde Døssing <
>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>> wrote:
>>>>>>>
>>>>>>> Updated https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053>> so we don't have
>>>>>>> org.apache.storm artifacts in the DEPENDENCY-LICENSES file. It's
>> ready for
>>>>>>> review if someone wants to look at it.
>>>>>>>
>>>>>>> Den tir. 13. aug. 2019 kl. 18.21 skrev Ethan Li <
>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>:
>>>>>>>
>>>>>>>> Thank you, Taylor. Will delete them.
>>>>>>>>
>>>>>>>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <ptgoetz@gmail.com <ma...@gmail.com>
>> <mailto:ptgoetz@gmail.com <ma...@gmail.com>>> wrote:
>>>>>>>>>
>>>>>>>>> Those can be safely deleted.
>>>>>>>>>
>>>>>>>>> -Taylor
>>>>>>>>>
>>>>>>>>>> On Aug 13, 2019, at 12:15 PM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>
>> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Do we need/want to clean up the release candidate from
>>>>>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>> <
>>>>>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>>> ?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>
>>>>>>>> <
>>>>>>>>
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>>
>>>>>>>> says we do. But we have a lot of rc in
>>>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>> <
>>>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>>>
>>>>>>>>>>
>>>>>>>>>> Just want to be absolutely sure about this. Thanks.
>>>>>>>>>>
>>>>>>>>>>> On Aug 13, 2019, at 10:56 AM, Ethan Li <
>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@gmail.com>>>
>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> That sounds better. It will be easier for release. Thank you for
>>>>>>>> looking into this.
>>>>>>>>>>>
>>>>>>>>>>>> On Aug 13, 2019, at 10:54 AM, Stig Rohde Døssing <
>>>>>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> 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 <
>>>>>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@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 <
>>>>>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Oops, sorry that's not right. The license plugin setup was
>> disabled
>>>>>>>> in
>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3031 <https://github.com/apache/storm/pull/3031> <
>> https://github.com/apache/storm/pull/3031 <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 <https://github.com/apache/storm/pull/3053> <
>> https://github.com/apache/storm/pull/3053 <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 <
>>>>>>>>>>>>>> stigdoessing@gmail.com <ma...@gmail.com> <mailto:stigdoessing@gmail.com <ma...@gmail.com>>>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> There's a script that can help you do it in
>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> <
>> https://github.com/apache/storm/pull/3053 <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 <
>>>>>>>>>>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@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?> <
>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>>
>>>>>>>> <
>>>>>>>>>>>>>>>>
>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
>> 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 <
>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@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 <
>> ptgoetz@gmail.com <ma...@gmail.com> <mailto:ptgoetz@gmail.com <ma...@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 <
>>>>>>>> ethanopensource@gmail.com <ma...@gmail.com> <mailto:ethanopensource@gmail.com <ma...@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>
>> <
>> 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>
>>>
>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>
>> 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 <
>>>>>>>> ethanopensource@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 <
>>>>>>>> ptgoetz@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 <
>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>> dagit@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 <
>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>> dagit@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 <
>>>>>>>>>>>>>>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>>>>>>>>>>>> <ma...@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 <
>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde
>> Døssing
>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call
>> <
>>>>>>>>>>>>>>>> bcall@apache.org
>>>>>>>>>>>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bcall@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev
>> Ethan
>>>>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>> hmclouro@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig
>> Rohde
>>>>>>>>>>>>> Døssing <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16
>> skrev
>>>>>>>> Ethan
>>>>>>>>>>>>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
Re: [DISCUSS] Next 2.x release
Posted by Stig Rohde Døssing <st...@gmail.com>.
I would be fine with just freezing (non-critical) merges during the
release process. These mails are public, so it's easy for anyone to see
whether a release is in progress.
If we want to do merges while releases are going on, I think your proposal
of using a release branch is fine. I'm not sure I understand why we need
the 2.1-SNAPSHOT version though?
Let's say we create release branch 2.1.0-branch from master. We roll the
master version to 2.1.1-SNAPSHOT (for example) after the 2.1.0 branch is
created. We then get a bug fix that should go in 2.1.0. In this case we
should merge it to 2.1.0-branch, then merge 2.1.0-branch to master. In Jira
we mark it as going in 2.1.0.
We then get a PR that shouldn't be included in 2.1.0. We just merge it to
master, and mark it as 2.1.1 in Jira.
Finally once 2.1.0 is released, we merge 2.1.0-branch into master and
delete 2.1.0-branch.
Why is there a need to 2.1-SNAPSHOT?
Den man. 19. aug. 2019 kl. 18.15 skrev Ethan Li <et...@gmail.com>:
> Many issues came up while I was preparing for 2.1.0 release. Freezing
> merge until the release is done is not practical. So I am proposing:
>
> 1. Once we decide to make a release, we create a new branch based on
> master and start release process.
> 2. During the new process, master is still open for backwards
> compatibility commits, including new features, bu g fixes, etc.
> 3. Only bug fixes will be merged to the new branch and we need to restart
> the release process to include the bug fixes.
> 4. To avoid too much confusion on pom versions when we merge new commits
> during the release process, we should use less concrete version. For
> example, in 2.1.x-branch, the pom version should be 2.1-SNAPSHOT, instead
> of 2.1.0-SNAPSHOT.
>
> For example,
>
> Let’s say we have a new branch 2.1.x-branch, the pom version is
> 2.1.0-SNAPSHOT. We start the release process and after running the mvn
> release:prepare -Pxxx command, the pom version changes to 2.1.1-SNAPSHOT,
> and before that a git tag v2.1.0 is created. Now if there is a bug fix we
> have to merge in, so we merge in and it’s actually merged in to
> 2.1.1-SNAPSHOT at this point if we don’t manually revert the pom version,
> which can be confusing. We can avoid this problem by just using
> 2.1-SNAPSHOT as the pom version. So it doesn’t have to change.
>
> Please let me know if there is any potential risk for doing this.
>
> Thanks
> Ethan
>
> > On Aug 19, 2019, at 10:25 AM, Ethan Li <et...@gmail.com>
> wrote:
> >
> > The pull request for the fix is
> https://github.com/apache/storm/pull/3106 <
> https://github.com/apache/storm/pull/3106>
> >
> >> On Aug 19, 2019, at 10:15 AM, Ethan Li <ethanopensource@gmail.com
> <ma...@gmail.com>> wrote:
> >>
> >> So I was preparing for a new release candidate i.e. rc3. I can build it
> from source without any problem. Then I set up a standalone cluster and
> submitted a WordCountTopology. The workers kept restarting because of
> >>
> >>
> >> 2019-08-19 15:09:49.635 o.a.s.t.ShellBolt Thread-30 [ERROR] Halting
> process: ShellBolt died. Command: [python, splitsentence.py], ProcessInfo
> pid:3756, name:split exitCode:-1, errorString:
> >> java.lang.IllegalArgumentException: command sync is not supported
> >> at
> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
> [storm-client-2.1.0.jar:2.1.0]
> >> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
> >> 2019-08-19 15:09:49.635 o.a.s.e.e.ReportError Thread-30 [ERROR] Error
> >> java.lang.IllegalArgumentException: command sync is not supported
> >> at
> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
> [storm-client-2.1.0.jar:2.1.0]
> >> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
> >> 2019-08-19 15:09:49.636 o.a.s.t.ShellBolt Thread-28 [ERROR] Halting
> process: ShellBolt died. Command: [python, splitsentence.py], ProcessInfo
> pid:3755, name:split exitCode:-1, errorString:
> >> java.lang.IllegalArgumentException: command sync is not supported
> >> at
> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
> [storm-client-2.1.0.jar:2.1.0]
> >> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
> >> 2019-08-19 15:09:49.637 o.a.s.e.e.ReportError Thread-28 [ERROR] Error
> >> java.lang.IllegalArgumentException: command sync is not supported
> >> at
> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
> [storm-client-2.1.0.jar:2.1.0]
> >> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
> >>
> >>
> >>
> >>
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> <
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367>
> I believe we shouldn’t throw exceptions here.
> >>
> >> Will make a pull request to fix it.
> >>
> >>
> >>
> >>> On Aug 14, 2019, at 11:11 PM, Ethan Li <ethanopensource@gmail.com
> <ma...@gmail.com>> wrote:
> >>>
> >>> Hi Taylor,
> >>>
> >>> Mostly I was able to follow the doc
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>,
> except:
> >>>
> >>> For Step 1, I used the following command as suggested.
> >>> mvn release:prepare -P dist,rat,externals,examples
> >>> mvn release:perform -P dist,rat,externals,examples
> >>>
> >>>
> >>> For Step3, I had to run "git checkout tags/v2.1.0 -b v2.1.0” so that
> I can run “mvn package” for storm-dist/binary and storm-dist/source based
> on v2.1.0. Otherwise if I run “mvn package” on 2.1.x-branch, it will fail
> because the pom version is “2.1.x-SNAPSHOT”.
> >>>
> >>> Then I find packages in storm-dist/binary/final-package/target and
> storm-dist/source/target, sign them, generate checksum and copy them to svn.
> >>>
> >>> I think there are something I should do. But please let me know if I
> was doing something wrong. I will also update the doc after the release
> is complete. Thank you very much!
> >>>
> >>> Ethan
> >>>
> >>>
> >>>> On Aug 14, 2019, at 12:24 PM, Ethan Li <ethanopensource@gmail.com
> <ma...@gmail.com>> wrote:
> >>>>
> >>>> I am continuing for another release candidate since the pr is merged.
> >>>>
> >>>>> On Aug 13, 2019, at 11:58 AM, Stig Rohde Døssing <
> stigdoessing@gmail.com <ma...@gmail.com>> wrote:
> >>>>>
> >>>>> Updated https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053> so we don't have
> >>>>> org.apache.storm artifacts in the DEPENDENCY-LICENSES file. It's
> ready for
> >>>>> review if someone wants to look at it.
> >>>>>
> >>>>> Den tir. 13. aug. 2019 kl. 18.21 skrev Ethan Li <
> ethanopensource@gmail.com <ma...@gmail.com>>:
> >>>>>
> >>>>>> Thank you, Taylor. Will delete them.
> >>>>>>
> >>>>>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <ptgoetz@gmail.com
> <ma...@gmail.com>> wrote:
> >>>>>>>
> >>>>>>> Those can be safely deleted.
> >>>>>>>
> >>>>>>> -Taylor
> >>>>>>>
> >>>>>>>> On Aug 13, 2019, at 12:15 PM, Ethan Li <ethanopensource@gmail.com
> <ma...@gmail.com>>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>> Do we need/want to clean up the release candidate from
> >>>>>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm> <
> >>>>>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm>> ?
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>>>>> <
> >>>>>>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >>
> >>>>>> says we do. But we have a lot of rc in
> >>>>>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/> <
> >>>>>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/>>
> >>>>>>>>
> >>>>>>>> Just want to be absolutely sure about this. Thanks.
> >>>>>>>>
> >>>>>>>>> On Aug 13, 2019, at 10:56 AM, Ethan Li <
> ethanopensource@gmail.com <ma...@gmail.com>>
> >>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> That sounds better. It will be easier for release. Thank you for
> >>>>>> looking into this.
> >>>>>>>>>
> >>>>>>>>>> On Aug 13, 2019, at 10:54 AM, Stig Rohde Døssing <
> >>>>>> stigdoessing@gmail.com <ma...@gmail.com>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> 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 <
> >>>>>> ethanopensource@gmail.com <ma...@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 <
> >>>>>> stigdoessing@gmail.com <ma...@gmail.com>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Oops, sorry that's not right. The license plugin setup was
> disabled
> >>>>>> in
> >>>>>>>>>>>> https://github.com/apache/storm/pull/3031 <
> 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 <
> 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 <
> >>>>>>>>>>>> stigdoessing@gmail.com <ma...@gmail.com>>:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> There's a script that can help you do it in
> >>>>>>>>>>>>> https://github.com/apache/storm/pull/3053 <
> 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 <
> >>>>>>>>>>> ethanopensource@gmail.com <ma...@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?>
> >>>>>> <
> >>>>>>>>>>>>>>
> 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 <
> ethanopensource@gmail.com <ma...@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 <
> ptgoetz@gmail.com <ma...@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 <
> >>>>>> ethanopensource@gmail.com <ma...@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
> >
> >>>>>>>>>>>>>> <
> >>>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>
> 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 <
> >>>>>> ethanopensource@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 <
> >>>>>> ptgoetz@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 <
> >>>>>>>>>>>>>> stigdoessing@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 <
> >>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>> stigdoessing@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 <
> >>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>> dagit@apache.org
> >>>>>>>>>>>>>> <mailto:
> >>>>>>>>>>>>>>>>>>>>>>> dagit@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 <
> >>>>>> dagit@apache.org
> >>>>>>>>>>>>>> <mailto:
> >>>>>>>>>>>>>>>>>>>>>>> dagit@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 <
> >>>>>>>>>>>>>>>>>>>>> dagit@apache.org
> >>>>>>>>>>>>>>>>>>>>>>> <ma...@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 <
> >>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde
> Døssing
> >>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call
> <
> >>>>>>>>>>>>>> bcall@apache.org
> >>>>>>>>>>>>>>>>>>>>>>> <mailto:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bcall@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev
> Ethan
> >>>>>> Li <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>>>>>>> hmclouro@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig
> Rohde
> >>>>>>>>>>> Døssing <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16
> skrev
> >>>>>> Ethan
> >>>>>>>>>>>>>> Li <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>
> >>
> >
>
>
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@gmail.com>.
Many issues came up while I was preparing for 2.1.0 release. Freezing merge until the release is done is not practical. So I am proposing:
1. Once we decide to make a release, we create a new branch based on master and start release process.
2. During the new process, master is still open for backwards compatibility commits, including new features, bug fixes, etc.
3. Only bug fixes will be merged to the new branch and we need to restart the release process to include the bug fixes.
4. To avoid too much confusion on pom versions when we merge new commits during the release process, we should use less concrete version. For example, in 2.1.x-branch, the pom version should be 2.1-SNAPSHOT, instead of 2.1.0-SNAPSHOT.
For example,
Let’s say we have a new branch 2.1.x-branch, the pom version is 2.1.0-SNAPSHOT. We start the release process and after running the mvn release:prepare -Pxxx command, the pom version changes to 2.1.1-SNAPSHOT, and before that a git tag v2.1.0 is created. Now if there is a bug fix we have to merge in, so we merge in and it’s actually merged in to 2.1.1-SNAPSHOT at this point if we don’t manually revert the pom version, which can be confusing. We can avoid this problem by just using 2.1-SNAPSHOT as the pom version. So it doesn’t have to change.
Please let me know if there is any potential risk for doing this.
Thanks
Ethan
> On Aug 19, 2019, at 10:25 AM, Ethan Li <et...@gmail.com> wrote:
>
> The pull request for the fix is https://github.com/apache/storm/pull/3106 <https://github.com/apache/storm/pull/3106>
>
>> On Aug 19, 2019, at 10:15 AM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>> wrote:
>>
>> So I was preparing for a new release candidate i.e. rc3. I can build it from source without any problem. Then I set up a standalone cluster and submitted a WordCountTopology. The workers kept restarting because of
>>
>>
>> 2019-08-19 15:09:49.635 o.a.s.t.ShellBolt Thread-30 [ERROR] Halting process: ShellBolt died. Command: [python, splitsentence.py], ProcessInfo pid:3756, name:split exitCode:-1, errorString:
>> java.lang.IllegalArgumentException: command sync is not supported
>> at org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366) [storm-client-2.1.0.jar:2.1.0]
>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>> 2019-08-19 15:09:49.635 o.a.s.e.e.ReportError Thread-30 [ERROR] Error
>> java.lang.IllegalArgumentException: command sync is not supported
>> at org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366) [storm-client-2.1.0.jar:2.1.0]
>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>> 2019-08-19 15:09:49.636 o.a.s.t.ShellBolt Thread-28 [ERROR] Halting process: ShellBolt died. Command: [python, splitsentence.py], ProcessInfo pid:3755, name:split exitCode:-1, errorString:
>> java.lang.IllegalArgumentException: command sync is not supported
>> at org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366) [storm-client-2.1.0.jar:2.1.0]
>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>> 2019-08-19 15:09:49.637 o.a.s.e.e.ReportError Thread-28 [ERROR] Error
>> java.lang.IllegalArgumentException: command sync is not supported
>> at org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366) [storm-client-2.1.0.jar:2.1.0]
>> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>>
>>
>>
>> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367> I believe we shouldn’t throw exceptions here.
>>
>> Will make a pull request to fix it.
>>
>>
>>
>>> On Aug 14, 2019, at 11:11 PM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> Hi Taylor,
>>>
>>> Mostly I was able to follow the doc https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>, except:
>>>
>>> For Step 1, I used the following command as suggested.
>>> mvn release:prepare -P dist,rat,externals,examples
>>> mvn release:perform -P dist,rat,externals,examples
>>>
>>>
>>> For Step3, I had to run "git checkout tags/v2.1.0 -b v2.1.0” so that I can run “mvn package” for storm-dist/binary and storm-dist/source based on v2.1.0. Otherwise if I run “mvn package” on 2.1.x-branch, it will fail because the pom version is “2.1.x-SNAPSHOT”.
>>>
>>> Then I find packages in storm-dist/binary/final-package/target and storm-dist/source/target, sign them, generate checksum and copy them to svn.
>>>
>>> I think there are something I should do. But please let me know if I was doing something wrong. I will also update the doc after the release is complete. Thank you very much!
>>>
>>> Ethan
>>>
>>>
>>>> On Aug 14, 2019, at 12:24 PM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>> wrote:
>>>>
>>>> I am continuing for another release candidate since the pr is merged.
>>>>
>>>>> On Aug 13, 2019, at 11:58 AM, Stig Rohde Døssing <stigdoessing@gmail.com <ma...@gmail.com>> wrote:
>>>>>
>>>>> Updated https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> so we don't have
>>>>> org.apache.storm artifacts in the DEPENDENCY-LICENSES file. It's ready for
>>>>> review if someone wants to look at it.
>>>>>
>>>>> Den tir. 13. aug. 2019 kl. 18.21 skrev Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>>:
>>>>>
>>>>>> Thank you, Taylor. Will delete them.
>>>>>>
>>>>>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <ptgoetz@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>
>>>>>>> Those can be safely deleted.
>>>>>>>
>>>>>>> -Taylor
>>>>>>>
>>>>>>>> On Aug 13, 2019, at 12:15 PM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>>
>>>>>> wrote:
>>>>>>>>
>>>>>>>> Do we need/want to clean up the release candidate from
>>>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>>>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>> ?
>>>>>>>>
>>>>>>>>
>>>>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>>>> <
>>>>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>>
>>>>>> says we do. But we have a lot of rc in
>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>>
>>>>>>>>
>>>>>>>> Just want to be absolutely sure about this. Thanks.
>>>>>>>>
>>>>>>>>> On Aug 13, 2019, at 10:56 AM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>>
>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> That sounds better. It will be easier for release. Thank you for
>>>>>> looking into this.
>>>>>>>>>
>>>>>>>>>> On Aug 13, 2019, at 10:54 AM, Stig Rohde Døssing <
>>>>>> stigdoessing@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>>>
>>>>>>>>>> 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 <
>>>>>> ethanopensource@gmail.com <ma...@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 <
>>>>>> stigdoessing@gmail.com <ma...@gmail.com>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Oops, sorry that's not right. The license plugin setup was disabled
>>>>>> in
>>>>>>>>>>>> https://github.com/apache/storm/pull/3031 <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 <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 <
>>>>>>>>>>>> stigdoessing@gmail.com <ma...@gmail.com>>:
>>>>>>>>>>>>
>>>>>>>>>>>>> There's a script that can help you do it in
>>>>>>>>>>>>> https://github.com/apache/storm/pull/3053 <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 <
>>>>>>>>>>> ethanopensource@gmail.com <ma...@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?>
>>>>>> <
>>>>>>>>>>>>>> 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 <ethanopensource@gmail.com <ma...@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 <ptgoetz@gmail.com <ma...@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 <
>>>>>> ethanopensource@gmail.com <ma...@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>
>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>> 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 <
>>>>>> ethanopensource@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 <
>>>>>> ptgoetz@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 <
>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>> dagit@apache.org
>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>> dagit@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 <
>>>>>> dagit@apache.org
>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>> dagit@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 <
>>>>>>>>>>>>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>>>>>>>>>> <ma...@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 <
>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing
>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <
>>>>>>>>>>>>>> bcall@apache.org
>>>>>>>>>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bcall@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan
>>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>> hmclouro@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde
>>>>>>>>>>> Døssing <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev
>>>>>> Ethan
>>>>>>>>>>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@gmail.com>.
The pull request for the fix is https://github.com/apache/storm/pull/3106 <https://github.com/apache/storm/pull/3106>
> On Aug 19, 2019, at 10:15 AM, Ethan Li <et...@gmail.com> wrote:
>
> So I was preparing for a new release candidate i.e. rc3. I can build it from source without any problem. Then I set up a standalone cluster and submitted a WordCountTopology. The workers kept restarting because of
>
>
> 2019-08-19 15:09:49.635 o.a.s.t.ShellBolt Thread-30 [ERROR] Halting process: ShellBolt died. Command: [python, splitsentence.py], ProcessInfo pid:3756, name:split exitCode:-1, errorString:
> java.lang.IllegalArgumentException: command sync is not supported
> at org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366) [storm-client-2.1.0.jar:2.1.0]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
> 2019-08-19 15:09:49.635 o.a.s.e.e.ReportError Thread-30 [ERROR] Error
> java.lang.IllegalArgumentException: command sync is not supported
> at org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366) [storm-client-2.1.0.jar:2.1.0]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
> 2019-08-19 15:09:49.636 o.a.s.t.ShellBolt Thread-28 [ERROR] Halting process: ShellBolt died. Command: [python, splitsentence.py], ProcessInfo pid:3755, name:split exitCode:-1, errorString:
> java.lang.IllegalArgumentException: command sync is not supported
> at org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366) [storm-client-2.1.0.jar:2.1.0]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
> 2019-08-19 15:09:49.637 o.a.s.e.e.ReportError Thread-28 [ERROR] Error
> java.lang.IllegalArgumentException: command sync is not supported
> at org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366) [storm-client-2.1.0.jar:2.1.0]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
>
>
>
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367> I believe we shouldn’t throw exceptions here.
>
> Will make a pull request to fix it.
>
>
>
>> On Aug 14, 2019, at 11:11 PM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>> wrote:
>>
>> Hi Taylor,
>>
>> Mostly I was able to follow the doc https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>, except:
>>
>> For Step 1, I used the following command as suggested.
>> mvn release:prepare -P dist,rat,externals,examples
>> mvn release:perform -P dist,rat,externals,examples
>>
>>
>> For Step3, I had to run "git checkout tags/v2.1.0 -b v2.1.0” so that I can run “mvn package” for storm-dist/binary and storm-dist/source based on v2.1.0. Otherwise if I run “mvn package” on 2.1.x-branch, it will fail because the pom version is “2.1.x-SNAPSHOT”.
>>
>> Then I find packages in storm-dist/binary/final-package/target and storm-dist/source/target, sign them, generate checksum and copy them to svn.
>>
>> I think there are something I should do. But please let me know if I was doing something wrong. I will also update the doc after the release is complete. Thank you very much!
>>
>> Ethan
>>
>>
>>> On Aug 14, 2019, at 12:24 PM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> I am continuing for another release candidate since the pr is merged.
>>>
>>>> On Aug 13, 2019, at 11:58 AM, Stig Rohde Døssing <stigdoessing@gmail.com <ma...@gmail.com>> wrote:
>>>>
>>>> Updated https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> so we don't have
>>>> org.apache.storm artifacts in the DEPENDENCY-LICENSES file. It's ready for
>>>> review if someone wants to look at it.
>>>>
>>>> Den tir. 13. aug. 2019 kl. 18.21 skrev Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>>:
>>>>
>>>>> Thank you, Taylor. Will delete them.
>>>>>
>>>>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <ptgoetz@gmail.com <ma...@gmail.com>> wrote:
>>>>>>
>>>>>> Those can be safely deleted.
>>>>>>
>>>>>> -Taylor
>>>>>>
>>>>>>> On Aug 13, 2019, at 12:15 PM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>>
>>>>> wrote:
>>>>>>>
>>>>>>> Do we need/want to clean up the release candidate from
>>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>> ?
>>>>>>>
>>>>>>>
>>>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>>> <
>>>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>>
>>>>> says we do. But we have a lot of rc in
>>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/> <
>>>>> https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>>
>>>>>>>
>>>>>>> Just want to be absolutely sure about this. Thanks.
>>>>>>>
>>>>>>>> On Aug 13, 2019, at 10:56 AM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>>
>>>>> wrote:
>>>>>>>>
>>>>>>>> That sounds better. It will be easier for release. Thank you for
>>>>> looking into this.
>>>>>>>>
>>>>>>>>> On Aug 13, 2019, at 10:54 AM, Stig Rohde Døssing <
>>>>> stigdoessing@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>>
>>>>>>>>> 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 <
>>>>> ethanopensource@gmail.com <ma...@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 <
>>>>> stigdoessing@gmail.com <ma...@gmail.com>>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Oops, sorry that's not right. The license plugin setup was disabled
>>>>> in
>>>>>>>>>>> https://github.com/apache/storm/pull/3031 <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 <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 <
>>>>>>>>>>> stigdoessing@gmail.com <ma...@gmail.com>>:
>>>>>>>>>>>
>>>>>>>>>>>> There's a script that can help you do it in
>>>>>>>>>>>> https://github.com/apache/storm/pull/3053 <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 <
>>>>>>>>>> ethanopensource@gmail.com <ma...@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? <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 <ethanopensource@gmail.com <ma...@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 <ptgoetz@gmail.com <ma...@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 <
>>>>> ethanopensource@gmail.com <ma...@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>
>>>>>>>>>>>>> <
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>> 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 <
>>>>> ethanopensource@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 <
>>>>> ptgoetz@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 <
>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>> ethanopensource@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 <
>>>>> dagit@apache.org
>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>> dagit@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 <
>>>>> dagit@apache.org
>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>> dagit@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 <
>>>>>>>>>>>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>>>>>>>>> <ma...@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 <
>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing
>>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <
>>>>>>>>>>>>> bcall@apache.org
>>>>>>>>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bcall@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan
>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>> hmclouro@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde
>>>>>>>>>> Døssing <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev
>>>>> Ethan
>>>>>>>>>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>
>
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@gmail.com>.
So I was preparing for a new release candidate i.e. rc3. I can build it from source without any problem. Then I set up a standalone cluster and submitted a WordCountTopology. The workers kept restarting because of
2019-08-19 15:09:49.635 o.a.s.t.ShellBolt Thread-30 [ERROR] Halting process: ShellBolt died. Command: [python, splitsentence.py], ProcessInfo pid:3756, name:split exitCode:-1, errorString:
java.lang.IllegalArgumentException: command sync is not supported
at org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366) [storm-client-2.1.0.jar:2.1.0]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
2019-08-19 15:09:49.635 o.a.s.e.e.ReportError Thread-30 [ERROR] Error
java.lang.IllegalArgumentException: command sync is not supported
at org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366) [storm-client-2.1.0.jar:2.1.0]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
2019-08-19 15:09:49.636 o.a.s.t.ShellBolt Thread-28 [ERROR] Halting process: ShellBolt died. Command: [python, splitsentence.py], ProcessInfo pid:3755, name:split exitCode:-1, errorString:
java.lang.IllegalArgumentException: command sync is not supported
at org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366) [storm-client-2.1.0.jar:2.1.0]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
2019-08-19 15:09:49.637 o.a.s.e.e.ReportError Thread-28 [ERROR] Error
java.lang.IllegalArgumentException: command sync is not supported
at org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366) [storm-client-2.1.0.jar:2.1.0]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367 <https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367> I believe we shouldn’t throw exceptions here.
Will make a pull request to fix it.
> On Aug 14, 2019, at 11:11 PM, Ethan Li <et...@gmail.com> wrote:
>
> Hi Taylor,
>
> Mostly I was able to follow the doc https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>, except:
>
> For Step 1, I used the following command as suggested.
> mvn release:prepare -P dist,rat,externals,examples
> mvn release:perform -P dist,rat,externals,examples
>
>
> For Step3, I had to run "git checkout tags/v2.1.0 -b v2.1.0” so that I can run “mvn package” for storm-dist/binary and storm-dist/source based on v2.1.0. Otherwise if I run “mvn package” on 2.1.x-branch, it will fail because the pom version is “2.1.x-SNAPSHOT”.
>
> Then I find packages in storm-dist/binary/final-package/target and storm-dist/source/target, sign them, generate checksum and copy them to svn.
>
> I think there are something I should do. But please let me know if I was doing something wrong. I will also update the doc after the release is complete. Thank you very much!
>
> Ethan
>
>
>> On Aug 14, 2019, at 12:24 PM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>> wrote:
>>
>> I am continuing for another release candidate since the pr is merged.
>>
>>> On Aug 13, 2019, at 11:58 AM, Stig Rohde Døssing <stigdoessing@gmail.com <ma...@gmail.com>> wrote:
>>>
>>> Updated https://github.com/apache/storm/pull/3053 <https://github.com/apache/storm/pull/3053> so we don't have
>>> org.apache.storm artifacts in the DEPENDENCY-LICENSES file. It's ready for
>>> review if someone wants to look at it.
>>>
>>> Den tir. 13. aug. 2019 kl. 18.21 skrev Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>>:
>>>
>>>> Thank you, Taylor. Will delete them.
>>>>
>>>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <ptgoetz@gmail.com <ma...@gmail.com>> wrote:
>>>>>
>>>>> Those can be safely deleted.
>>>>>
>>>>> -Taylor
>>>>>
>>>>>> On Aug 13, 2019, at 12:15 PM, Ethan Li <ethanopensource@gmail.com <ma...@gmail.com>>
>>>> wrote:
>>>>>>
>>>>>> Do we need/want to clean up the release candidate from
>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> <
>>>> https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm>> ?
>>>>>>
>>>>>>
>>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>> <
>>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>>> says we do. But we have a lot of rc in
>>>> https://dist.apache.org/repos/dist/dev/storm/ <
>>>> https://dist.apache.org/repos/dist/dev/storm/>
>>>>>>
>>>>>> Just want to be absolutely sure about this. Thanks.
>>>>>>
>>>>>>> On Aug 13, 2019, at 10:56 AM, Ethan Li <et...@gmail.com>
>>>> wrote:
>>>>>>>
>>>>>>> That sounds better. It will be easier for release. Thank you for
>>>> looking into this.
>>>>>>>
>>>>>>>> On Aug 13, 2019, at 10:54 AM, Stig Rohde Døssing <
>>>> stigdoessing@gmail.com> wrote:
>>>>>>>>
>>>>>>>> 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 <
>>>> ethanopensource@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 <
>>>> stigdoessing@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 <
>>>>>>>>>> stigdoessing@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 <
>>>>>>>>> ethanopensource@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 <ethanopensource@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 <ptgoetz@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 <
>>>> ethanopensource@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 <
>>>> ethanopensource@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 <
>>>> ptgoetz@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 <
>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>> ethanopensource@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 <
>>>> dagit@apache.org
>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>> dagit@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 <
>>>> dagit@apache.org
>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>> dagit@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 <
>>>>>>>>>>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>>>>>>>> <ma...@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 <
>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing
>>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <
>>>>>>>>>>>> bcall@apache.org
>>>>>>>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bcall@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan
>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>> hmclouro@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde
>>>>>>>>> Døssing <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev
>>>> Ethan
>>>>>>>>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>
>
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@gmail.com>.
Hi Taylor,
Mostly I was able to follow the doc https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote <https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote>, except:
For Step 1, I used the following command as suggested.
mvn release:prepare -P dist,rat,externals,examples
mvn release:perform -P dist,rat,externals,examples
For Step3, I had to run "git checkout tags/v2.1.0 -b v2.1.0” so that I can run “mvn package” for storm-dist/binary and storm-dist/source based on v2.1.0. Otherwise if I run “mvn package” on 2.1.x-branch, it will fail because the pom version is “2.1.x-SNAPSHOT”.
Then I find packages in storm-dist/binary/final-package/target and storm-dist/source/target, sign them, generate checksum and copy them to svn.
I think there are something I should do. But please let me know if I was doing something wrong. I will also update the doc after the release is complete. Thank you very much!
Ethan
> On Aug 14, 2019, at 12:24 PM, Ethan Li <et...@gmail.com> wrote:
>
> I am continuing for another release candidate since the pr is merged.
>
>> On Aug 13, 2019, at 11:58 AM, Stig Rohde Døssing <st...@gmail.com> wrote:
>>
>> Updated https://github.com/apache/storm/pull/3053 so we don't have
>> org.apache.storm artifacts in the DEPENDENCY-LICENSES file. It's ready for
>> review if someone wants to look at it.
>>
>> Den tir. 13. aug. 2019 kl. 18.21 skrev Ethan Li <et...@gmail.com>:
>>
>>> Thank you, Taylor. Will delete them.
>>>
>>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <pt...@gmail.com> wrote:
>>>>
>>>> Those can be safely deleted.
>>>>
>>>> -Taylor
>>>>
>>>>> On Aug 13, 2019, at 12:15 PM, Ethan Li <et...@gmail.com>
>>> wrote:
>>>>>
>>>>> Do we need/want to clean up the release candidate from
>>> https://dist.apache.org/repos/dist/dev/storm <
>>> https://dist.apache.org/repos/dist/dev/storm> ?
>>>>>
>>>>>
>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
>>> <
>>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>>> says we do. But we have a lot of rc in
>>> https://dist.apache.org/repos/dist/dev/storm/ <
>>> https://dist.apache.org/repos/dist/dev/storm/>
>>>>>
>>>>> Just want to be absolutely sure about this. Thanks.
>>>>>
>>>>>> On Aug 13, 2019, at 10:56 AM, Ethan Li <et...@gmail.com>
>>> wrote:
>>>>>>
>>>>>> That sounds better. It will be easier for release. Thank you for
>>> looking into this.
>>>>>>
>>>>>>> On Aug 13, 2019, at 10:54 AM, Stig Rohde Døssing <
>>> stigdoessing@gmail.com> wrote:
>>>>>>>
>>>>>>> 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 <
>>> ethanopensource@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 <
>>> stigdoessing@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 <
>>>>>>>>> stigdoessing@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 <
>>>>>>>> ethanopensource@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 <ethanopensource@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 <ptgoetz@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 <
>>> ethanopensource@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 <
>>> ethanopensource@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 <
>>> ptgoetz@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 <
>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>> ethanopensource@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 <
>>> dagit@apache.org
>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>> dagit@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 <
>>> dagit@apache.org
>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>> dagit@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 <
>>>>>>>>>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>>>>>>> <ma...@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 <
>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing
>>> <
>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <
>>>>>>>>>>> bcall@apache.org
>>>>>>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bcall@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan
>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>> hmclouro@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde
>>>>>>>> Døssing <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev
>>> Ethan
>>>>>>>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@gmail.com>.
I am continuing for another release candidate since the pr is merged.
> On Aug 13, 2019, at 11:58 AM, Stig Rohde Døssing <st...@gmail.com> wrote:
>
> Updated https://github.com/apache/storm/pull/3053 so we don't have
> org.apache.storm artifacts in the DEPENDENCY-LICENSES file. It's ready for
> review if someone wants to look at it.
>
> Den tir. 13. aug. 2019 kl. 18.21 skrev Ethan Li <et...@gmail.com>:
>
>> Thank you, Taylor. Will delete them.
>>
>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <pt...@gmail.com> wrote:
>>>
>>> Those can be safely deleted.
>>>
>>> -Taylor
>>>
>>>> On Aug 13, 2019, at 12:15 PM, Ethan Li <et...@gmail.com>
>> wrote:
>>>>
>>>> Do we need/want to clean up the release candidate from
>> https://dist.apache.org/repos/dist/dev/storm <
>> https://dist.apache.org/repos/dist/dev/storm> ?
>>>>
>>>>
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
>> <
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
>> says we do. But we have a lot of rc in
>> https://dist.apache.org/repos/dist/dev/storm/ <
>> https://dist.apache.org/repos/dist/dev/storm/>
>>>>
>>>> Just want to be absolutely sure about this. Thanks.
>>>>
>>>>> On Aug 13, 2019, at 10:56 AM, Ethan Li <et...@gmail.com>
>> wrote:
>>>>>
>>>>> That sounds better. It will be easier for release. Thank you for
>> looking into this.
>>>>>
>>>>>> On Aug 13, 2019, at 10:54 AM, Stig Rohde Døssing <
>> stigdoessing@gmail.com> wrote:
>>>>>>
>>>>>> 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 <
>> ethanopensource@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 <
>> stigdoessing@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 <
>>>>>>>> stigdoessing@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 <
>>>>>>> ethanopensource@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 <ethanopensource@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 <ptgoetz@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 <
>> ethanopensource@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 <
>> ethanopensource@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 <
>> ptgoetz@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 <
>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>> ethanopensource@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 <
>> dagit@apache.org
>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>> dagit@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 <
>> dagit@apache.org
>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>> dagit@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 <
>>>>>>>>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>>>>>> <ma...@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 <
>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing
>> <
>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <
>>>>>>>>>> bcall@apache.org
>>>>>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bcall@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 <
>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan
>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>> hmclouro@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 <
>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde
>>>>>>> Døssing <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev
>> Ethan
>>>>>>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>>
Re: [DISCUSS] Next 2.x release
Posted by Stig Rohde Døssing <st...@gmail.com>.
Updated https://github.com/apache/storm/pull/3053 so we don't have
org.apache.storm artifacts in the DEPENDENCY-LICENSES file. It's ready for
review if someone wants to look at it.
Den tir. 13. aug. 2019 kl. 18.21 skrev Ethan Li <et...@gmail.com>:
> Thank you, Taylor. Will delete them.
>
> > On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <pt...@gmail.com> wrote:
> >
> > Those can be safely deleted.
> >
> > -Taylor
> >
> >> On Aug 13, 2019, at 12:15 PM, Ethan Li <et...@gmail.com>
> wrote:
> >>
> >> Do we need/want to clean up the release candidate from
> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm> ?
> >>
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails>
> says we do. But we have a lot of rc in
> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/>
> >>
> >> Just want to be absolutely sure about this. Thanks.
> >>
> >>> On Aug 13, 2019, at 10:56 AM, Ethan Li <et...@gmail.com>
> wrote:
> >>>
> >>> That sounds better. It will be easier for release. Thank you for
> looking into this.
> >>>
> >>>> On Aug 13, 2019, at 10:54 AM, Stig Rohde Døssing <
> stigdoessing@gmail.com> wrote:
> >>>>
> >>>> 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 <
> ethanopensource@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 <
> stigdoessing@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 <
> >>>>>> stigdoessing@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 <
> >>>>> ethanopensource@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 <ethanopensource@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 <ptgoetz@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 <
> ethanopensource@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 <
> ethanopensource@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 <
> ptgoetz@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 <
> >>>>>>>> stigdoessing@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 <
> >>>>>>>> ethanopensource@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 <
> >>>>>>>> stigdoessing@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 <
> >>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>> ethanopensource@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 <
> dagit@apache.org
> >>>>>>>> <mailto:
> >>>>>>>>>>>>>>>>> dagit@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 <
> dagit@apache.org
> >>>>>>>> <mailto:
> >>>>>>>>>>>>>>>>> dagit@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 <
> >>>>>>>>>>>>>>> dagit@apache.org
> >>>>>>>>>>>>>>>>> <ma...@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 <
> >>>>>>>>>>>>>>> ethanopensource@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing
> <
> >>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
> >>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <
> >>>>>>>> bcall@apache.org
> >>>>>>>>>>>>>>>>> <mailto:
> >>>>>>>>>>>>>>>>>>>>>>>>>>> bcall@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 <
> >>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan
> Li <
> >>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>> hmclouro@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 <
> >>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde
> >>>>> Døssing <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev
> Ethan
> >>>>>>>> Li <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>
> >>>>>
> >>>
> >>
> >
> >
>
>
>
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@gmail.com>.
Thank you, Taylor. Will delete them.
> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <pt...@gmail.com> wrote:
>
> Those can be safely deleted.
>
> -Taylor
>
>> On Aug 13, 2019, at 12:15 PM, Ethan Li <et...@gmail.com> wrote:
>>
>> Do we need/want to clean up the release candidate from https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> ?
>>
>> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails> says we do. But we have a lot of rc in https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>
>>
>> Just want to be absolutely sure about this. Thanks.
>>
>>> On Aug 13, 2019, at 10:56 AM, Ethan Li <et...@gmail.com> wrote:
>>>
>>> That sounds better. It will be easier for release. Thank you for looking into this.
>>>
>>>> On Aug 13, 2019, at 10:54 AM, Stig Rohde Døssing <st...@gmail.com> wrote:
>>>>
>>>> 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 <et...@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 <st...@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 <
>>>>>> stigdoessing@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 <
>>>>> ethanopensource@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 <et...@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 <pt...@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 <et...@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 <et...@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 <pt...@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 <
>>>>>>>> stigdoessing@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 <
>>>>>>>> ethanopensource@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 <
>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>> ethanopensource@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 <dagit@apache.org
>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>> dagit@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 <dagit@apache.org
>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>> dagit@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 <
>>>>>>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>>>> <ma...@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 <
>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <
>>>>>>>> bcall@apache.org
>>>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>>>> bcall@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 <
>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>> hmclouro@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 <
>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde
>>>>> Døssing <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan
>>>>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>>
>>>
>>
>
>
Re: [DISCUSS] Next 2.x release
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
Those can be safely deleted.
-Taylor
> On Aug 13, 2019, at 12:15 PM, Ethan Li <et...@gmail.com> wrote:
>
> Do we need/want to clean up the release candidate from https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> ?
>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails> says we do. But we have a lot of rc in https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>
>
> Just want to be absolutely sure about this. Thanks.
>
>> On Aug 13, 2019, at 10:56 AM, Ethan Li <et...@gmail.com> wrote:
>>
>> That sounds better. It will be easier for release. Thank you for looking into this.
>>
>>> On Aug 13, 2019, at 10:54 AM, Stig Rohde Døssing <st...@gmail.com> wrote:
>>>
>>> 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 <et...@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 <st...@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 <
>>>>> stigdoessing@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 <
>>>> ethanopensource@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 <et...@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 <pt...@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 <et...@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 <et...@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 <pt...@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 <
>>>>>>> stigdoessing@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 <
>>>>>>> ethanopensource@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 <
>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>> ethanopensource@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 <dagit@apache.org
>>>>>>> <mailto:
>>>>>>>>>>>>>>>> dagit@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 <dagit@apache.org
>>>>>>> <mailto:
>>>>>>>>>>>>>>>> dagit@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 <
>>>>>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>>> <ma...@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 <
>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <
>>>>>>> bcall@apache.org
>>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>>> bcall@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 <
>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>> hmclouro@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 <
>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde
>>>> Døssing <
>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan
>>>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>>
>
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@gmail.com>.
Do we need/want to clean up the release candidate from https://dist.apache.org/repos/dist/dev/storm <https://dist.apache.org/repos/dist/dev/storm> ?
https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails <https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails> says we do. But we have a lot of rc in https://dist.apache.org/repos/dist/dev/storm/ <https://dist.apache.org/repos/dist/dev/storm/>
Just want to be absolutely sure about this. Thanks.
> On Aug 13, 2019, at 10:56 AM, Ethan Li <et...@gmail.com> wrote:
>
> That sounds better. It will be easier for release. Thank you for looking into this.
>
>> On Aug 13, 2019, at 10:54 AM, Stig Rohde Døssing <st...@gmail.com> wrote:
>>
>> 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 <et...@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 <st...@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 <
>>>> stigdoessing@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 <
>>> ethanopensource@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 <et...@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 <pt...@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 <et...@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 <et...@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 <pt...@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 <
>>>>>> stigdoessing@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 <
>>>>>> ethanopensource@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 <
>>>>>> stigdoessing@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 <
>>>>>>>>>>>>> ethanopensource@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 <
>>>>>> ethanopensource@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 <dagit@apache.org
>>>>>> <mailto:
>>>>>>>>>>>>>>> dagit@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 <dagit@apache.org
>>>>>> <mailto:
>>>>>>>>>>>>>>> dagit@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 <
>>>>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>>> <ma...@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 <
>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Yes thanks.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <
>>>>>> bcall@apache.org
>>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>>> bcall@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 <
>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>> hmclouro@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 <
>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde
>>> Døssing <
>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan
>>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>
>>>
>
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@gmail.com>.
That sounds better. It will be easier for release. Thank you for looking into this.
> On Aug 13, 2019, at 10:54 AM, Stig Rohde Døssing <st...@gmail.com> wrote:
>
> 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 <et...@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 <st...@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 <
>>> stigdoessing@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 <
>> ethanopensource@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 <et...@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 <pt...@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 <et...@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 <et...@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 <pt...@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 <
>>>>> stigdoessing@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 <
>>>>> ethanopensource@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 <
>>>>> stigdoessing@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 <
>>>>>>>>>>>> ethanopensource@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 <
>>>>> ethanopensource@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 <dagit@apache.org
>>>>> <mailto:
>>>>>>>>>>>>>> dagit@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 <dagit@apache.org
>>>>> <mailto:
>>>>>>>>>>>>>> dagit@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 <
>>>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>>>> <ma...@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 <
>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Yes thanks.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <
>>>>> bcall@apache.org
>>>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>>>> bcall@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 <
>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>> hmclouro@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 <
>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde
>> Døssing <
>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan
>>>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>
>>
Re: [DISCUSS] Next 2.x release
Posted by Stig Rohde Døssing <st...@gmail.com>.
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 <et...@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 <st...@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 <
> > stigdoessing@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 <
> ethanopensource@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 <et...@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 <pt...@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 <et...@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 <et...@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 <pt...@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 <
> >>> stigdoessing@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 <
> >>> ethanopensource@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 <
> >>> stigdoessing@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 <
> >>>>>>>>>> ethanopensource@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 <
> >>> ethanopensource@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 <dagit@apache.org
> >>> <mailto:
> >>>>>>>>>>>> dagit@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 <dagit@apache.org
> >>> <mailto:
> >>>>>>>>>>>> dagit@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 <
> >>>>>>>>>> dagit@apache.org
> >>>>>>>>>>>> <ma...@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 <
> >>>>>>>>>> ethanopensource@gmail.com>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Yes thanks.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
> >>>>>>>>>>>>>>>>>> stigdoessing@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 <
> >>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <
> >>> bcall@apache.org
> >>>>>>>>>>>> <mailto:
> >>>>>>>>>>>>>>>>>>>>>> bcall@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 <
> >>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
> >>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>> hmclouro@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 <
> >>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde
> Døssing <
> >>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan
> >>> Li <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>>
>
>
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@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 <st...@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 <
> stigdoessing@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 <ethanopensource@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 <et...@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 <pt...@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 <et...@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 <et...@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 <pt...@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 <
>>> stigdoessing@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 <
>>> ethanopensource@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 <
>>> stigdoessing@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 <
>>>>>>>>>> ethanopensource@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 <
>>> ethanopensource@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 <dagit@apache.org
>>> <mailto:
>>>>>>>>>>>> dagit@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 <dagit@apache.org
>>> <mailto:
>>>>>>>>>>>> dagit@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 <
>>>>>>>>>> dagit@apache.org
>>>>>>>>>>>> <ma...@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 <
>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Yes thanks.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <
>>> bcall@apache.org
>>>>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>>>>> bcall@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 <
>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>> hmclouro@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 <
>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan
>>> Li <
>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
Re: [DISCUSS] Next 2.x release
Posted by Stig Rohde Døssing <st...@gmail.com>.
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 <
stigdoessing@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 <ethanopensource@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 <et...@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 <pt...@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 <et...@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 <et...@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 <pt...@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 <
>> stigdoessing@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 <
>> ethanopensource@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 <
>> stigdoessing@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 <
>> >>>>>>> ethanopensource@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 <
>> ethanopensource@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 <dagit@apache.org
>> <mailto:
>> >>>>>>>>> dagit@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 <dagit@apache.org
>> <mailto:
>> >>>>>>>>> dagit@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 <
>> >>>>>>> dagit@apache.org
>> >>>>>>>>> <ma...@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 <
>> >>>>>>> ethanopensource@gmail.com>
>> >>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> Yes thanks.
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
>> >>>>>>>>>>>>>>> stigdoessing@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 <
>> >>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <
>> bcall@apache.org
>> >>>>>>>>> <mailto:
>> >>>>>>>>>>>>>>>>>>> bcall@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 <
>> >>>>>>>>>>>>>>> stigdoessing@gmail.com>
>> >>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
>> >>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>> >>>>>>> hmclouro@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 <
>> >>>>>>>>>>>>>>> ethanopensource@gmail.com>
>> >>>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
>> >>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>> >>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>> >>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>> >>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan
>> Li <
>> >>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>> >>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>>
>>
Re: [DISCUSS] Next 2.x release
Posted by Stig Rohde Døssing <st...@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 <et...@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 <et...@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 <pt...@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 <et...@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 <et...@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 <pt...@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 <
> stigdoessing@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 <
> ethanopensource@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 <
> stigdoessing@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 <
> >>>>>>> ethanopensource@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 <ethanopensource@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 <dagit@apache.org
> <mailto:
> >>>>>>>>> dagit@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 <dagit@apache.org
> <mailto:
> >>>>>>>>> dagit@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 <
> >>>>>>> dagit@apache.org
> >>>>>>>>> <ma...@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 <
> >>>>>>> ethanopensource@gmail.com>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Yes thanks.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
> >>>>>>>>>>>>>>> stigdoessing@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 <
> >>>>>>>>>>>>>>> ethanopensource@gmail.com>:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <
> bcall@apache.org
> >>>>>>>>> <mailto:
> >>>>>>>>>>>>>>>>>>> bcall@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 <
> >>>>>>>>>>>>>>> stigdoessing@gmail.com>
> >>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
> >>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>> hmclouro@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 <
> >>>>>>>>>>>>>>> ethanopensource@gmail.com>
> >>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
> >>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
> >>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li
> <
> >>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >
>
>
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@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 <et...@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 <pt...@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 <et...@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 <et...@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 <pt...@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 <st...@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 <et...@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 <st...@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 <
>>>>>>> ethanopensource@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 <et...@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 <dagit@apache.org <mailto:
>>>>>>>>> dagit@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 <dagit@apache.org <mailto:
>>>>>>>>> dagit@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 <
>>>>>>> dagit@apache.org
>>>>>>>>> <ma...@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 <
>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Yes thanks.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <bcall@apache.org
>>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>>> bcall@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 <
>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>> hmclouro@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 <
>>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
>>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@gmail.com>.
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 <pt...@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 <et...@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 <et...@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 <pt...@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 <st...@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 <et...@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 <st...@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 <
>>>>>> ethanopensource@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 <et...@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 <dagit@apache.org <mailto:
>>>>>>>> dagit@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 <dagit@apache.org <mailto:
>>>>>>>> dagit@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 <
>>>>>> dagit@apache.org
>>>>>>>> <ma...@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 <
>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Yes thanks.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <bcall@apache.org
>>>>>>>> <mailto:
>>>>>>>>>>>>>>>>>> bcall@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 <
>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>> hmclouro@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 <
>>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
>>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
>
Re: [DISCUSS] Next 2.x release
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
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 <et...@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 <et...@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 <pt...@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 <st...@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 <et...@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 <st...@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 <
>>>>> ethanopensource@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 <et...@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 <dagit@apache.org <mailto:
>>>>>>> dagit@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 <dagit@apache.org <mailto:
>>>>>>> dagit@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 <
>>>>> dagit@apache.org
>>>>>>> <ma...@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 <
>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Yes thanks.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <bcall@apache.org
>>>>>>> <mailto:
>>>>>>>>>>>>>>>>> bcall@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 <
>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>> hmclouro@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 <
>>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
>>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>
>
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@gmail.com>.
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 <et...@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 <pt...@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 <st...@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 <et...@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 <st...@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 <
>>>> ethanopensource@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 <et...@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 <dagit@apache.org <mailto:
>>>>>> dagit@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 <dagit@apache.org <mailto:
>>>>>> dagit@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 <
>>>> dagit@apache.org
>>>>>> <ma...@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 <
>>>> ethanopensource@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes thanks.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <bcall@apache.org
>>>>>> <mailto:
>>>>>>>>>>>>>>>> bcall@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 <
>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>> hmclouro@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 <
>>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
>>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
>>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@gmail.com>.
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 <pt...@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 <st...@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 <et...@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 <st...@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 <
>>> ethanopensource@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 <et...@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 <dagit@apache.org <mailto:
>>>>> dagit@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 <dagit@apache.org <mailto:
>>>>> dagit@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 <
>>> dagit@apache.org
>>>>> <ma...@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 <
>>> ethanopensource@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Yes thanks.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <bcall@apache.org
>>>>> <mailto:
>>>>>>>>>>>>>>> bcall@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 <
>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
>>>>>>>>>>>>>>> ethanopensource@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 <
>>> hmclouro@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 <
>>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
>>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
>>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>
>>>
>
Re: [DISCUSS] Next 2.x release
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
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 <st...@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 <et...@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 <st...@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 <
>> ethanopensource@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 <et...@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 <dagit@apache.org <mailto:
>>>> dagit@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 <dagit@apache.org <mailto:
>>>> dagit@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 <
>> dagit@apache.org
>>>> <ma...@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 <
>> ethanopensource@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Yes thanks.
>>>>>>>>>>>>
>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <bcall@apache.org
>>>> <mailto:
>>>>>>>>>>>>>> bcall@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 <
>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
>>>>>>>>>>>>>> ethanopensource@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 <
>> hmclouro@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 <
>>>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
>>>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
>>>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>>>> stigdoessing@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?
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>
>>
Re: [DISCUSS] Next 2.x release
Posted by Stig Rohde Døssing <st...@gmail.com>.
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 <et...@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 <st...@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 <
> ethanopensource@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 <et...@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 <dagit@apache.org <mailto:
> >> dagit@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 <dagit@apache.org <mailto:
> >> dagit@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 <
> dagit@apache.org
> >> <ma...@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 <
> ethanopensource@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Yes thanks.
> >>>>>>>>>>
> >>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
> >>>>>>>> stigdoessing@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 <
> >>>>>>>> ethanopensource@gmail.com>:
> >>>>>>>>>>>
> >>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <bcall@apache.org
> >> <mailto:
> >>>>>>>>>>>> bcall@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 <
> >>>>>>>> stigdoessing@gmail.com>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
> >>>>>>>>>>>> ethanopensource@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 <
> hmclouro@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 <
> >>>>>>>> ethanopensource@gmail.com>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
> >>>>>>>>>>>>>> stigdoessing@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 <
> >>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>> stigdoessing@gmail.com>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
> >>>>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>>>> stigdoessing@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?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>
> >>>
> >>
> >>
>
>
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@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 <st...@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 <et...@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 <et...@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 <dagit@apache.org <mailto:
>> dagit@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 <dagit@apache.org <mailto:
>> dagit@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 <dagit@apache.org
>> <ma...@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 <et...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Yes thanks.
>>>>>>>>>>
>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
>>>>>>>> stigdoessing@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 <
>>>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>>>
>>>>>>>>>>>> I got my pgp key signed by Bryan W. Call <bcall@apache.org
>> <mailto:
>>>>>>>>>>>> bcall@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 <
>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
>>>>>>>>>>>> ethanopensource@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 <hmclouro@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 <
>>>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
>>>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
>>>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>>>> stigdoessing@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?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>
>>>
>>
>>
Re: [DISCUSS] Next 2.x release
Posted by Stig Rohde Døssing <st...@gmail.com>.
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 <et...@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 <et...@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 <dagit@apache.org <mailto:
> dagit@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 <dagit@apache.org <mailto:
> dagit@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 <dagit@apache.org
> <ma...@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 <et...@gmail.com>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>> Yes thanks.
> >>>>>>>>
> >>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
> >>>>>> stigdoessing@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 <
> >>>>>> ethanopensource@gmail.com>:
> >>>>>>>>>
> >>>>>>>>>> I got my pgp key signed by Bryan W. Call <bcall@apache.org
> <mailto:
> >>>>>>>>>> bcall@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 <
> >>>>>> stigdoessing@gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
> >>>>>>>>>>>
> >>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
> >>>>>>>>>> ethanopensource@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 <hmclouro@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 <
> >>>>>> ethanopensource@gmail.com>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> Thanks Stig. I will look into it.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
> >>>>>>>>>>>> stigdoessing@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 <
> >>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>> stigdoessing@gmail.com>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
> >>>>>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>>>>> stigdoessing@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?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>
> >
>
>
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@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 <et...@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 <dagit@apache.org <ma...@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 <dagit@apache.org <ma...@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 <dagit@apache.org <ma...@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 <et...@gmail.com>
>>>>>> wrote:
>>>>>>>>
>>>>>>>> Yes thanks.
>>>>>>>>
>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
>>>>>> stigdoessing@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 <
>>>>>> ethanopensource@gmail.com>:
>>>>>>>>>
>>>>>>>>>> I got my pgp key signed by Bryan W. Call <bcall@apache.org <mailto:
>>>>>>>>>> bcall@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 <
>>>>>> stigdoessing@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>>
>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
>>>>>>>>>> ethanopensource@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 <hm...@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 <
>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>> stigdoessing@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?
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>
>
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@gmail.com>.
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> 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> 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
>>>
>>> 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>:
>>>>
>>>>> 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/).
>>>>>
>>>>> Apache Traffic Server does something like this, to name one project:
>>>>>
>>>>> 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 <et...@gmail.com>
>>>>> wrote:
>>>>>>>
>>>>>>> Yes thanks.
>>>>>>>
>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
>>>>> stigdoessing@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 <
>>>>> ethanopensource@gmail.com>:
>>>>>>>>
>>>>>>>>> I got my pgp key signed by Bryan W. Call <bcall@apache.org <mailto:
>>>>>>>>> bcall@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 <
>>>>> stigdoessing@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>
>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
>>>>>>>>> ethanopensource@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 <hm...@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 <
>>>>> ethanopensource@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>> stigdoessing@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?
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>
Re: [DISCUSS] Next 2.x release
Posted by Derek Dagit <da...@apache.org>.
> 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> 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
> >
> > 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>:
> >>
> >>> 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/).
> >>>
> >>> Apache Traffic Server does something like this, to name one project:
> >>>
> >>> 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 <et...@gmail.com>
> >>> wrote:
> >>>>>
> >>>>> Yes thanks.
> >>>>>
> >>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
> >>> stigdoessing@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 <
> >>> ethanopensource@gmail.com>:
> >>>>>>
> >>>>>>> I got my pgp key signed by Bryan W. Call <bcall@apache.org <mailto:
> >>>>>>> bcall@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 <
> >>> stigdoessing@gmail.com>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
> >>>>>>>>
> >>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
> >>>>>>> ethanopensource@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 <hm...@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 <
> >>> ethanopensource@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Thanks Stig. I will look into it.
> >>>>>>>>>>>
> >>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
> >>>>>>>>> stigdoessing@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 <
> >>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>> stigdoessing@gmail.com>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Sounds great, thanks Ethan.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
> >>>>>>>>>>>>> ethanopensource@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 <
> >>>>>>>>>>>>> stigdoessing@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?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>
> >>>
>
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@gmail.com>.
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> 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
>
> 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>:
>>
>>> 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/).
>>>
>>> Apache Traffic Server does something like this, to name one project:
>>>
>>> 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 <et...@gmail.com>
>>> wrote:
>>>>>
>>>>> Yes thanks.
>>>>>
>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
>>> stigdoessing@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 <
>>> ethanopensource@gmail.com>:
>>>>>>
>>>>>>> I got my pgp key signed by Bryan W. Call <bcall@apache.org <mailto:
>>>>>>> bcall@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 <
>>> stigdoessing@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>
>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
>>>>>>> ethanopensource@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 <hm...@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 <
>>> ethanopensource@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>
>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>> stigdoessing@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?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>
Re: [DISCUSS] Next 2.x release
Posted by Derek Dagit <da...@apache.org>.
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
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>:
>
> > 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/).
> >
> > Apache Traffic Server does something like this, to name one project:
> >
> > 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 <et...@gmail.com>
> > wrote:
> > > >
> > > > Yes thanks.
> > > >
> > > >> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
> > stigdoessing@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 <
> > ethanopensource@gmail.com>:
> > > >>
> > > >>> I got my pgp key signed by Bryan W. Call <bcall@apache.org <mailto:
> > > >>> bcall@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 <
> > stigdoessing@gmail.com>
> > > >>> wrote:
> > > >>>>
> > > >>>> Thanks Ethan, yes 2.1.0 makes sense.
> > > >>>>
> > > >>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
> > > >>> ethanopensource@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 <hm...@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 <
> > ethanopensource@gmail.com>
> > > >>>>> wrote:
> > > >>>>>>
> > > >>>>>>> Thanks Stig. I will look into it.
> > > >>>>>>>
> > > >>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
> > > >>>>> stigdoessing@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 <
> > > >>>>>>> ethanopensource@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 <
> > > >>>>>>> stigdoessing@gmail.com>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>> Sounds great, thanks Ethan.
> > > >>>>>>>>>>
> > > >>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
> > > >>>>>>>>> ethanopensource@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 <
> > > >>>>>>>>> stigdoessing@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?
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>
> > > >>>
> > > >
> > >
> >
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@gmail.com>.
Stig,
It’s fine with me if we did this on purpose. But I think it makes it hard to follow semantic versioning (https://semver.org/ <https://semver.org/>). The semantic versioning is about:
Given a version number MAJOR.MINOR.PATCH, increment the:
1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards compatible manner, and
3. PATCH version when you make backwards compatible bug fixes.
To make discussion easier, I am taking 1.x release line as an example, although it’s already dropped and we are not going to do new release on 1.x.
Currently we have 1.x (1.2.4-SNAPSHOT). We tend to merge commits to 1.x no matter if the commit is about new functionality or bug fixes. When we decide to do a release, we choose release version based on what’s already merged in. If there is no new functionality, the 1.x release will be 1.2.4. Then we update 1.x to 1.2.5-SNAPSHOT. But if there are new functionality we choose to release 1.3.0. But now we have to create 1.2.x-branch based on current 1.x, which already includes new functionalities. The result of it is that 1.2.x-branch includes not only bug fixes but also new functionalities, which breaks semantic versioning.
There is no high risk for user to upgrade minor version. But the current way we are doing release doesn’t follow a clear versioning and we probably want to improve it.
So I propose to stick with semantic versioning and release based on it. We released 2.0.0 and the current master branch is 2.0.1-SNAPSHOT. But we merged many new functionalities so we want to release 2.1.0 instead of 2.0.1. So we then create a 2.1.x-branch and release 2.1.0 from it. And switch master to 2.2.0-SNAPSHOT. After this, developers should only work on master branch and only bug fixes should be merged to 2.1.x-branch.
We decided to release more frequently. At some point we will have too many branches to maintain. So I propose to drop some old release branches when we have a new release to keep a certain number of branches we maintain. For example, when we release 2.3.0, we can drop 2.1.x-branch and older branches. So we have master, 2.3.x-branch and 2.2.x-branch to maintain.
As for 2.0.x-branch, I am fine with simply asking users to upgrade to 2.1.0 if there is an issue with 2.0.0 since there is no much risk involved. It’s also acceptable because we are kind of migrating from a loose semantic versioning to a strict one.
> On Aug 9, 2019, at 7:35 AM, Stig Rohde Døssing <st...@gmail.com> wrote:
>
> Ethan,
>
> I think the idea has been that master is just the latest unreleased
> version. The same goes for 1.x-branch, which is the latest unreleased 1.x
> version (so 1.2.4 right now). I think we've been branching when necessary
> rather than proactively, so e.g. when work requiring breaking changes to
> 1.x started, the 1.x-branch was created and master became 2.0.0-SNAPSHOT. I
> don't see an issue branching proactively by cutting a 2.1.x-branch
> immediately, but I'm not sure it's necessary. It means that any change
> going in 2.1.1 needs to be merged to master and also 2.1.x, instead of
> master just being 2.1.x until we need to bump to 2.2.x. I see it as just
> adding an extra unnecessary branch, because until master contains something
> that should go in 2.2.x and not 2.1.x, the branches have the same contents.
> Branching at the point where 2.2.x and 2.1.x would diverge makes more sense
> IMO.
>
> I think at least for 2.1.0, I'd rather we ask users to upgrade to 2.1.0.
> Otherwise, we need to create the 2.0.x branch from v2.0.0 and then go
> cherry pick any changes that are already in master that should be in a
> 2.0.1 release. Is there anything in 2.1.0 that's risky enough that we want
> to put the effort of also doing a 2.0.1 in?
>
> Derek,
>
> I think the period of support so far has been based mostly around whether
> anyone wants to put in the work to support old branches. We've been
> dropping support once no one shows an interest in supporting the old
> branches anymore.
>
> When you say a branch is LTS, I assume you mean we're promising to keep
> putting out bugfix releases for that line? It seems like a fine idea,
> assuming we limit ourselves to a couple of branches (maintaining 2.x and a
> bunch of 1.x branches has been unpleasant in the past, but that probably
> has more to do with slow release cadence). Regarding setting a date for
> when a release line will no longer be supported, I'm not sure how easy it
> is to set a date up front. For instance, I would have a hard time setting a
> date for the end of 2.x support until there's a 3.x release on the horizon.
>
> 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, this also
> seems to be what Traffic Server is doing. If we're following semver,
> upgrading to minor versions should be safe, and I don't see the value of
> promising to maintain e.g. both 2.0.x and 2.1.x for long periods.
>
> 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.
>
> Den fre. 9. aug. 2019 kl. 00.15 skrev Derek Dagit <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/).
>>
>> Apache Traffic Server does something like this, to name one project:
>>
>> 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 <et...@gmail.com>
>> wrote:
>>>>
>>>> Yes thanks.
>>>>
>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
>> stigdoessing@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 <
>> ethanopensource@gmail.com>:
>>>>>
>>>>>> I got my pgp key signed by Bryan W. Call <bcall@apache.org <mailto:
>>>>>> bcall@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 <
>> stigdoessing@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>
>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
>>>>>> ethanopensource@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 <hm...@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 <
>> ethanopensource@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>
>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
>>>>>>>> stigdoessing@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 <
>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>> stigdoessing@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?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>
>>
Re: [DISCUSS] Next 2.x release
Posted by Stig Rohde Døssing <st...@gmail.com>.
Ethan,
I think the idea has been that master is just the latest unreleased
version. The same goes for 1.x-branch, which is the latest unreleased 1.x
version (so 1.2.4 right now). I think we've been branching when necessary
rather than proactively, so e.g. when work requiring breaking changes to
1.x started, the 1.x-branch was created and master became 2.0.0-SNAPSHOT. I
don't see an issue branching proactively by cutting a 2.1.x-branch
immediately, but I'm not sure it's necessary. It means that any change
going in 2.1.1 needs to be merged to master and also 2.1.x, instead of
master just being 2.1.x until we need to bump to 2.2.x. I see it as just
adding an extra unnecessary branch, because until master contains something
that should go in 2.2.x and not 2.1.x, the branches have the same contents.
Branching at the point where 2.2.x and 2.1.x would diverge makes more sense
IMO.
I think at least for 2.1.0, I'd rather we ask users to upgrade to 2.1.0.
Otherwise, we need to create the 2.0.x branch from v2.0.0 and then go
cherry pick any changes that are already in master that should be in a
2.0.1 release. Is there anything in 2.1.0 that's risky enough that we want
to put the effort of also doing a 2.0.1 in?
Derek,
I think the period of support so far has been based mostly around whether
anyone wants to put in the work to support old branches. We've been
dropping support once no one shows an interest in supporting the old
branches anymore.
When you say a branch is LTS, I assume you mean we're promising to keep
putting out bugfix releases for that line? It seems like a fine idea,
assuming we limit ourselves to a couple of branches (maintaining 2.x and a
bunch of 1.x branches has been unpleasant in the past, but that probably
has more to do with slow release cadence). Regarding setting a date for
when a release line will no longer be supported, I'm not sure how easy it
is to set a date up front. For instance, I would have a hard time setting a
date for the end of 2.x support until there's a 3.x release on the horizon.
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, this also
seems to be what Traffic Server is doing. If we're following semver,
upgrading to minor versions should be safe, and I don't see the value of
promising to maintain e.g. both 2.0.x and 2.1.x for long periods.
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.
Den fre. 9. aug. 2019 kl. 00.15 skrev Derek Dagit <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/).
>
> Apache Traffic Server does something like this, to name one project:
>
> 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 <et...@gmail.com>
> wrote:
> > >
> > > Yes thanks.
> > >
> > >> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
> stigdoessing@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 <
> ethanopensource@gmail.com>:
> > >>
> > >>> I got my pgp key signed by Bryan W. Call <bcall@apache.org <mailto:
> > >>> bcall@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 <
> stigdoessing@gmail.com>
> > >>> wrote:
> > >>>>
> > >>>> Thanks Ethan, yes 2.1.0 makes sense.
> > >>>>
> > >>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
> > >>> ethanopensource@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 <hm...@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 <
> ethanopensource@gmail.com>
> > >>>>> wrote:
> > >>>>>>
> > >>>>>>> Thanks Stig. I will look into it.
> > >>>>>>>
> > >>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
> > >>>>> stigdoessing@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 <
> > >>>>>>> ethanopensource@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 <
> > >>>>>>> stigdoessing@gmail.com>
> > >>>>>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>> Sounds great, thanks Ethan.
> > >>>>>>>>>>
> > >>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
> > >>>>>>>>> ethanopensource@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 <
> > >>>>>>>>> stigdoessing@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?
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>>>
> > >>>
> > >>>
> > >
> >
>
Re: [DISCUSS] Next 2.x release
Posted by Derek Dagit <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/).
Apache Traffic Server does something like this, to name one project:
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 <et...@gmail.com> wrote:
> >
> > Yes thanks.
> >
> >> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <st...@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 <et...@gmail.com>:
> >>
> >>> I got my pgp key signed by Bryan W. Call <bcall@apache.org <mailto:
> >>> bcall@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 <st...@gmail.com>
> >>> wrote:
> >>>>
> >>>> Thanks Ethan, yes 2.1.0 makes sense.
> >>>>
> >>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
> >>> ethanopensource@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 <hm...@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 <et...@gmail.com>
> >>>>> wrote:
> >>>>>>
> >>>>>>> Thanks Stig. I will look into it.
> >>>>>>>
> >>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
> >>>>> stigdoessing@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 <
> >>>>>>> ethanopensource@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 <
> >>>>>>> stigdoessing@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Sounds great, thanks Ethan.
> >>>>>>>>>>
> >>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
> >>>>>>>>> ethanopensource@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 <
> >>>>>>>>> stigdoessing@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?
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >
>
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@gmail.com>.
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 <et...@gmail.com> wrote:
>
> Yes thanks.
>
>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <st...@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 <et...@gmail.com>:
>>
>>> I got my pgp key signed by Bryan W. Call <bcall@apache.org <mailto:
>>> bcall@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 <st...@gmail.com>
>>> wrote:
>>>>
>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>
>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
>>> ethanopensource@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 <hm...@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 <et...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>>> Thanks Stig. I will look into it.
>>>>>>>
>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
>>>>> stigdoessing@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 <
>>>>>>> ethanopensource@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 <
>>>>>>> stigdoessing@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>>
>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
>>>>>>>>> ethanopensource@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 <
>>>>>>>>> stigdoessing@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?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@gmail.com>.
Yes thanks.
> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <st...@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 <et...@gmail.com>:
>
>> I got my pgp key signed by Bryan W. Call <bcall@apache.org <mailto:
>> bcall@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 <st...@gmail.com>
>> wrote:
>>>
>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>
>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
>> ethanopensource@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 <hm...@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 <et...@gmail.com>
>>>> wrote:
>>>>>
>>>>>> Thanks Stig. I will look into it.
>>>>>>
>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
>>>> stigdoessing@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 <
>>>>>> ethanopensource@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 <
>>>>>> stigdoessing@gmail.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Sounds great, thanks Ethan.
>>>>>>>>>
>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
>>>>>>>> ethanopensource@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 <
>>>>>>>> stigdoessing@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?
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>
Re: [DISCUSS] Next 2.x release
Posted by Stig Rohde Døssing <st...@gmail.com>.
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 <et...@gmail.com>:
> I got my pgp key signed by Bryan W. Call <bcall@apache.org <mailto:
> bcall@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 <st...@gmail.com>
> wrote:
> >
> > Thanks Ethan, yes 2.1.0 makes sense.
> >
> > Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
> ethanopensource@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 <hm...@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 <et...@gmail.com>
> >> wrote:
> >>>
> >>>> Thanks Stig. I will look into it.
> >>>>
> >>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
> >> stigdoessing@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 <
> >>>> ethanopensource@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 <
> >>>> stigdoessing@gmail.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Sounds great, thanks Ethan.
> >>>>>>>
> >>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
> >>>>>> ethanopensource@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 <
> >>>>>> stigdoessing@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?
> >>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>
> >>>>
> >>
> >>
>
>
Re: [DISCUSS] Next 2.x release
Posted by Ethan Li <et...@gmail.com>.
I got my pgp key signed by Bryan W. Call <bcall@apache.org <ma...@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 <st...@gmail.com> wrote:
>
> Thanks Ethan, yes 2.1.0 makes sense.
>
> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <et...@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 <hm...@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 <et...@gmail.com>
>> wrote:
>>>
>>>> Thanks Stig. I will look into it.
>>>>
>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
>> stigdoessing@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 <
>>>> ethanopensource@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 <
>>>> stigdoessing@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Sounds great, thanks Ethan.
>>>>>>>
>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
>>>>>> ethanopensource@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 <
>>>>>> stigdoessing@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?
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>
>>