Re: [DISCUSS] Next 2.x release

[Stig Rohde Døssing]

Sounds good

Den ons. 21. aug. 2019 kl. 17.27 skrev Ethan Li :

> 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  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  > 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 <
> ethanopensou...@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 <
> stigdoess...@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 <
> >>> ethanopensou...@gmail.com   ethanopensou...@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 <
> >>> stigdoess...@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 

Re: [DISCUSS] Next 2.x release

[Ethan Li]

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  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 > > 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 > >:
>> 
>>> 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 >>> >
>>> 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 <
>>> ethanopensou...@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 <
>>> stigdoess...@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.

Re: [DISCUSS] Next 2.x release

[Ethan Li]

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  
> 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  >:
> 
>> 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 
>> 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 <
>> ethanopensou...@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 <
>> stigdoess...@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 <
 ethanopensou...@gmail.com  
 > 
 > ethanopensou...@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 

Re: [DISCUSS] Next 2.x release

[Stig Rohde Døssing]

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

> 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 
> 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 <
> ethanopensou...@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 <
> stigdoess...@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 <
> >> ethanopensou...@gmail.com   ethanopensou...@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
>  

Re: [DISCUSS] Next 2.x release

[Ethan Li]

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  
> 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  >:
> 
>> 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 
>> 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 <
>> ethanopensou...@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  >
 wrote:
> 
> The pull request for 

Re: [DISCUSS] Next 2.x release

[Stig Rohde Døssing]

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 :

> 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 
> 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 <
> ethanopensou...@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 
> >> 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  
> >> >>
> 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: 

Re: [DISCUSS] Next 2.x release

[Ethan Li]

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

Re: [DISCUSS] Next 2.x release

[Stig Rohde Døssing]

 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 :

> 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 
> 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  > 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  > wrote:
> >>>
> >>> Hi Taylor,

Re: [DISCUSS] Next 2.x release

[Ethan Li]

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  wrote:
> 
> The pull request for the fix is https://github.com/apache/storm/pull/3106 
> 
> 
>> On Aug 19, 2019, at 10:15 AM, Ethan Li > > 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
>>  
>> 
>>  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 >> > wrote:
>>> 
>>> Hi Taylor,
>>> 
>>> Mostly I was able to follow the doc 
>>> 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 

Re: [DISCUSS] Next 2.x release

[Ethan Li]

The pull request for the fix is https://github.com/apache/storm/pull/3106 


> On Aug 19, 2019, at 10:15 AM, Ethan Li  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
>  
> 
>  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 > > wrote:
>> 
>> Hi Taylor,
>> 
>> Mostly I was able to follow the doc 
>> 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 >> > 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 >>> > 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 >>> >:
 
> Thank you, Taylor. Will delete them.
> 
>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz > > wrote:
>> 
>> Those can be safely deleted.
>> 
>> -Taylor
>> 
>>> On Aug 13, 2019, at 12:15 PM, Ethan Li >> >
> 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
>  
> 
> <
> 

Re: [DISCUSS] Next 2.x release

[Ethan Li]

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
 

 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  wrote:
> 
> Hi Taylor,
> 
> Mostly I was able to follow the doc 
> 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 > > 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 >> > 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 >> >:
>>> 
 Thank you, Taylor. Will delete them.
 
> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz  > wrote:
> 
> Those can be safely deleted.
> 
> -Taylor
> 
>> On Aug 13, 2019, at 12:15 PM, Ethan Li > >
 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 
 wrote:
>>> 
>>> That sounds better. It will be easier for 

Re: [DISCUSS] Next 2.x release

[Ethan Li]

Hi Taylor,

Mostly I was able to follow the doc 
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  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  
>> 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 :
>> 
>>> Thank you, Taylor. Will delete them.
>>> 
 On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz  wrote:
 
 Those can be safely deleted.
 
 -Taylor
 
> On Aug 13, 2019, at 12:15 PM, Ethan Li 
>>> 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 
>>> 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 <
>>> stigdoess...@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 <
>>> ethanopensou...@gmail.com>:
>>> 
 Thanks Stig.
 
 In this case, we probably should abort release process and get this
>>> merged
 into master first. Also we need to make sure it works with “mvn
 release:prepare” since “ mvn release:prepare” will automatically
>>> push two
 commits. For example,
 
 (1) [maven-release-plugin] prepare release v2.1.0:  this commit
>>> changes
 the pom version to 2.1.0, push the commit, and then create a git tag
>>> v2.1.0.
 
 (2)  [maven-release-plugin] prepare for next development iteration:
>>> this
 commit changes the pom version to 2.1.1-SNAPSHOT.
 
 
 We need DEPENDENCY-LICENSES to be updated on every step.
 
 
 
> On Aug 13, 2019, at 10:24 AM, Stig Rohde Døssing <
>>> stigdoess...@gmail.com>
 wrote:
> 
> Oops, sorry that's not right. The license plugin setup was disabled
>>> in
> https://github.com/apache/storm/pull/3031 due to a bug in the
>>> license
> plugin. It is added back in
>>> https://github.com/apache/storm/pull/3053,
> where we've upgraded the plugin. Until that PR goes in, we can't
>>> easily
> regenerate DEPENDENCY-LICENSES.
> 
> Den tir. 13. aug. 2019 kl. 17.15 skrev Stig Rohde Døssing <
> stigdoess...@gmail.com>:
> 
>> There's a script that can help you do it in
>> https://github.com/apache/storm/pull/3053. It checks the
>> DEPENDENCY-LICENSES and LICENSE-binary contain the right
>>> dependencies,
 and
>> prints which licenses are redundant or should be added.
>> 
>> For DEPENDENCY-LICENSES specifically you can run "mvn
>> license:aggregate-add-third-party@generate-and-check-licenses
>> -Dlicense.skipAggregateAddThirdParty=false -B" in the project
>>> root. It
>> should update the file for you.
>> 
>> Den tir. 13. aug. 2019 kl. 

Re: [DISCUSS] Next 2.x release

[Ethan Li]

I am continuing for another release candidate since the pr is merged. 

> On Aug 13, 2019, at 11:58 AM, Stig Rohde Døssing  
> 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 :
> 
>> Thank you, Taylor. Will delete them.
>> 
>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz  wrote:
>>> 
>>> Those can be safely deleted.
>>> 
>>> -Taylor
>>> 
 On Aug 13, 2019, at 12:15 PM, Ethan Li 
>> 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 
>> 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 <
>> stigdoess...@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 <
>> ethanopensou...@gmail.com>:
>> 
>>> Thanks Stig.
>>> 
>>> In this case, we probably should abort release process and get this
>> merged
>>> into master first. Also we need to make sure it works with “mvn
>>> release:prepare” since “ mvn release:prepare” will automatically
>> push two
>>> commits. For example,
>>> 
>>> (1) [maven-release-plugin] prepare release v2.1.0:  this commit
>> changes
>>> the pom version to 2.1.0, push the commit, and then create a git tag
>> v2.1.0.
>>> 
>>> (2)  [maven-release-plugin] prepare for next development iteration:
>> this
>>> commit changes the pom version to 2.1.1-SNAPSHOT.
>>> 
>>> 
>>> We need DEPENDENCY-LICENSES to be updated on every step.
>>> 
>>> 
>>> 
 On Aug 13, 2019, at 10:24 AM, Stig Rohde Døssing <
>> stigdoess...@gmail.com>
>>> wrote:
 
 Oops, sorry that's not right. The license plugin setup was disabled
>> in
 https://github.com/apache/storm/pull/3031 due to a bug in the
>> license
 plugin. It is added back in
>> https://github.com/apache/storm/pull/3053,
 where we've upgraded the plugin. Until that PR goes in, we can't
>> easily
 regenerate DEPENDENCY-LICENSES.
 
 Den tir. 13. aug. 2019 kl. 17.15 skrev Stig Rohde Døssing <
 stigdoess...@gmail.com>:
 
> There's a script that can help you do it in
> https://github.com/apache/storm/pull/3053. It checks the
> DEPENDENCY-LICENSES and LICENSE-binary contain the right
>> dependencies,
>>> and
> prints which licenses are redundant or should be added.
> 
> For DEPENDENCY-LICENSES specifically you can run "mvn
> license:aggregate-add-third-party@generate-and-check-licenses
> -Dlicense.skipAggregateAddThirdParty=false -B" in the project
>> root. It
> should update the file for you.
> 
> Den tir. 13. aug. 2019 kl. 17.06 skrev Ethan Li <
>>> ethanopensou...@gmail.com
>> :
> 
>> Hi Stig,
>> 
>> How do we update
>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?
>> <
>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>
>> Is
>> there a command I can use? Or I just replace strings manually?
>> 
>> Thanks
>> Ethan
>> 
>>> On Aug 12, 2019, at 3:54 PM, Ethan Li >> 
>> 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 >> 
>> wrote:
 
 Yes. Is you public key in that file? If not you should add it.
 
 -Taylor
 
> On Aug 12, 2019, at 4:15 PM, Ethan Li <
>> ethanopensou...@gmail.com>
>> wrote:
> 
> I have one more question before I can start a vote.
> 
> In previous [VOTE] thread, Taylor always has this:
> 
> The release 

Re: [DISCUSS] Next 2.x release

[Stig Rohde Døssing]

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 :

> Thank you, Taylor. Will delete them.
>
> > On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz  wrote:
> >
> > Those can be safely deleted.
> >
> > -Taylor
> >
> >> On Aug 13, 2019, at 12:15 PM, Ethan Li 
> 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 
> 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 <
> stigdoess...@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 <
> ethanopensou...@gmail.com>:
> 
> > Thanks Stig.
> >
> > In this case, we probably should abort release process and get this
> merged
> > into master first. Also we need to make sure it works with “mvn
> > release:prepare” since “ mvn release:prepare” will automatically
> push two
> > commits. For example,
> >
> > (1) [maven-release-plugin] prepare release v2.1.0:  this commit
> changes
> > the pom version to 2.1.0, push the commit, and then create a git tag
> v2.1.0.
> >
> > (2)  [maven-release-plugin] prepare for next development iteration:
> this
> > commit changes the pom version to 2.1.1-SNAPSHOT.
> >
> >
> > We need DEPENDENCY-LICENSES to be updated on every step.
> >
> >
> >
> >> On Aug 13, 2019, at 10:24 AM, Stig Rohde Døssing <
> stigdoess...@gmail.com>
> > wrote:
> >>
> >> Oops, sorry that's not right. The license plugin setup was disabled
> in
> >> https://github.com/apache/storm/pull/3031 due to a bug in the
> license
> >> plugin. It is added back in
> https://github.com/apache/storm/pull/3053,
> >> where we've upgraded the plugin. Until that PR goes in, we can't
> easily
> >> regenerate DEPENDENCY-LICENSES.
> >>
> >> Den tir. 13. aug. 2019 kl. 17.15 skrev Stig Rohde Døssing <
> >> stigdoess...@gmail.com>:
> >>
> >>> There's a script that can help you do it in
> >>> https://github.com/apache/storm/pull/3053. It checks the
> >>> DEPENDENCY-LICENSES and LICENSE-binary contain the right
> dependencies,
> > and
> >>> prints which licenses are redundant or should be added.
> >>>
> >>> For DEPENDENCY-LICENSES specifically you can run "mvn
> >>> license:aggregate-add-third-party@generate-and-check-licenses
> >>> -Dlicense.skipAggregateAddThirdParty=false -B" in the project
> root. It
> >>> should update the file for you.
> >>>
> >>> Den tir. 13. aug. 2019 kl. 17.06 skrev Ethan Li <
> > ethanopensou...@gmail.com
>  :
> >>>
>  Hi Stig,
> 
>  How do we update
>  https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?
> <
>  https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>
> Is
>  there a command I can use? Or I just replace strings manually?
> 
>  Thanks
>  Ethan
> 
> > On Aug 12, 2019, at 3:54 PM, Ethan Li  >
>  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  >
>  wrote:
> >>
> >> Yes. Is you public key in that file? If not you should add it.
> >>
> >> -Taylor
> >>
> >>> On Aug 12, 2019, at 4:15 PM, Ethan Li <
> ethanopensou...@gmail.com>
>  wrote:
> >>>
> >>> I have one more question before I can start a vote.
> >>>
> >>> In previous [VOTE] thread, Taylor always has this:
> >>>
> >>> The release artifacts are signed with the following key:
> >>>
> 
> >
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
>  <
> 
> >
> 

Re: [DISCUSS] Next 2.x release

[Ethan Li]

Thank you, Taylor. Will delete them. 

> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz  wrote:
> 
> Those can be safely deleted.
> 
> -Taylor
> 
>> On Aug 13, 2019, at 12:15 PM, Ethan Li  wrote:
>> 
>> Do we need/want to clean up the release candidate from 
>> https://dist.apache.org/repos/dist/dev/storm 
>>  ?
>> 
>> 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/ 
>> 
>> 
>> Just want to be absolutely sure about this. Thanks.
>> 
>>> On Aug 13, 2019, at 10:56 AM, Ethan Li  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  
 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 
 :
 
> 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 
> wrote:
>> 
>> Oops, sorry that's not right. The license plugin setup was disabled in
>> https://github.com/apache/storm/pull/3031 due to a bug in the license
>> plugin. It is added back in https://github.com/apache/storm/pull/3053,
>> where we've upgraded the plugin. Until that PR goes in, we can't easily
>> regenerate DEPENDENCY-LICENSES.
>> 
>> Den tir. 13. aug. 2019 kl. 17.15 skrev Stig Rohde Døssing <
>> stigdoess...@gmail.com>:
>> 
>>> There's a script that can help you do it in
>>> https://github.com/apache/storm/pull/3053. It checks the
>>> DEPENDENCY-LICENSES and LICENSE-binary contain the right dependencies,
> and
>>> prints which licenses are redundant or should be added.
>>> 
>>> For DEPENDENCY-LICENSES specifically you can run "mvn
>>> license:aggregate-add-third-party@generate-and-check-licenses
>>> -Dlicense.skipAggregateAddThirdParty=false -B" in the project root. It
>>> should update the file for you.
>>> 
>>> Den tir. 13. aug. 2019 kl. 17.06 skrev Ethan Li <
> ethanopensou...@gmail.com
 :
>>> 
 Hi Stig,
 
 How do we update
 https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
 https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> Is
 there a command I can use? Or I just replace strings manually?
 
 Thanks
 Ethan
 
> On Aug 12, 2019, at 3:54 PM, Ethan Li 
 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 
 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 
 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 
 wrote:
 
 Thanks Stig and Taylor! It worked. I will continue 

Re: [DISCUSS] Next 2.x release

[P. Taylor Goetz]

Those can be safely deleted.

-Taylor

> On Aug 13, 2019, at 12:15 PM, Ethan Li  wrote:
> 
> Do we need/want to clean up the release candidate from 
> https://dist.apache.org/repos/dist/dev/storm 
>  ?
> 
> 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/ 
> 
> 
> Just want to be absolutely sure about this. Thanks.
> 
>> On Aug 13, 2019, at 10:56 AM, Ethan Li  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  
>>> 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 :
>>> 
 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 
 wrote:
> 
> Oops, sorry that's not right. The license plugin setup was disabled in
> https://github.com/apache/storm/pull/3031 due to a bug in the license
> plugin. It is added back in https://github.com/apache/storm/pull/3053,
> where we've upgraded the plugin. Until that PR goes in, we can't easily
> regenerate DEPENDENCY-LICENSES.
> 
> Den tir. 13. aug. 2019 kl. 17.15 skrev Stig Rohde Døssing <
> stigdoess...@gmail.com>:
> 
>> There's a script that can help you do it in
>> https://github.com/apache/storm/pull/3053. It checks the
>> DEPENDENCY-LICENSES and LICENSE-binary contain the right dependencies,
 and
>> prints which licenses are redundant or should be added.
>> 
>> For DEPENDENCY-LICENSES specifically you can run "mvn
>> license:aggregate-add-third-party@generate-and-check-licenses
>> -Dlicense.skipAggregateAddThirdParty=false -B" in the project root. It
>> should update the file for you.
>> 
>> Den tir. 13. aug. 2019 kl. 17.06 skrev Ethan Li <
 ethanopensou...@gmail.com
>>> :
>> 
>>> Hi Stig,
>>> 
>>> How do we update
>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> Is
>>> there a command I can use? Or I just replace strings manually?
>>> 
>>> Thanks
>>> Ethan
>>> 
 On Aug 12, 2019, at 3:54 PM, Ethan Li 
>>> 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 
>>> 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 
>>> 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 
>>> 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 
>>> wrote:
 
 For the 2.x version lines, there are a bunch of 

Re: [DISCUSS] Next 2.x release

[Ethan Li]

Do we need/want to clean up the release candidate from 
https://dist.apache.org/repos/dist/dev/storm 
 ?

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/ 


Just want to be absolutely sure about this. Thanks.

> On Aug 13, 2019, at 10:56 AM, Ethan Li  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  
>> 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 :
>> 
>>> 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 
>>> wrote:
 
 Oops, sorry that's not right. The license plugin setup was disabled in
 https://github.com/apache/storm/pull/3031 due to a bug in the license
 plugin. It is added back in https://github.com/apache/storm/pull/3053,
 where we've upgraded the plugin. Until that PR goes in, we can't easily
 regenerate DEPENDENCY-LICENSES.
 
 Den tir. 13. aug. 2019 kl. 17.15 skrev Stig Rohde Døssing <
 stigdoess...@gmail.com>:
 
> There's a script that can help you do it in
> https://github.com/apache/storm/pull/3053. It checks the
> DEPENDENCY-LICENSES and LICENSE-binary contain the right dependencies,
>>> and
> prints which licenses are redundant or should be added.
> 
> For DEPENDENCY-LICENSES specifically you can run "mvn
> license:aggregate-add-third-party@generate-and-check-licenses
> -Dlicense.skipAggregateAddThirdParty=false -B" in the project root. It
> should update the file for you.
> 
> Den tir. 13. aug. 2019 kl. 17.06 skrev Ethan Li <
>>> ethanopensou...@gmail.com
>> :
> 
>> Hi Stig,
>> 
>> How do we update
>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> Is
>> there a command I can use? Or I just replace strings manually?
>> 
>> Thanks
>> Ethan
>> 
>>> On Aug 12, 2019, at 3:54 PM, Ethan Li 
>> 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 
>> 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 
>> 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 
>> 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 
>> 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, 

Re: [DISCUSS] Next 2.x release

[Ethan Li]

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  
> 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 :
> 
>> 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 
>> wrote:
>>> 
>>> Oops, sorry that's not right. The license plugin setup was disabled in
>>> https://github.com/apache/storm/pull/3031 due to a bug in the license
>>> plugin. It is added back in https://github.com/apache/storm/pull/3053,
>>> where we've upgraded the plugin. Until that PR goes in, we can't easily
>>> regenerate DEPENDENCY-LICENSES.
>>> 
>>> Den tir. 13. aug. 2019 kl. 17.15 skrev Stig Rohde Døssing <
>>> stigdoess...@gmail.com>:
>>> 
 There's a script that can help you do it in
 https://github.com/apache/storm/pull/3053. It checks the
 DEPENDENCY-LICENSES and LICENSE-binary contain the right dependencies,
>> and
 prints which licenses are redundant or should be added.
 
 For DEPENDENCY-LICENSES specifically you can run "mvn
 license:aggregate-add-third-party@generate-and-check-licenses
 -Dlicense.skipAggregateAddThirdParty=false -B" in the project root. It
 should update the file for you.
 
 Den tir. 13. aug. 2019 kl. 17.06 skrev Ethan Li <
>> ethanopensou...@gmail.com
> :
 
> Hi Stig,
> 
> How do we update
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> Is
> there a command I can use? Or I just replace strings manually?
> 
> Thanks
> Ethan
> 
>> On Aug 12, 2019, at 3:54 PM, Ethan Li 
> 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 
> 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 
> 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 
> 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 
> wrote:
>> 
>> For the 2.x version lines, there are a bunch of profiles you need
> to enable. This is what I use when preparing a release:
>> 
>> -P dist,include-shaded-deps,rat,externals,examples
>> 
>> -Taylor
>> 
>>> On Aug 12, 2019, at 9:27 AM, Stig Rohde Døssing <
> stigdoess...@gmail.com> wrote:
>>> 
>>> Try enabling the "dist" profile by adding "-P
> dist,externals,examples" to
>>> the command you're running. See
>>> https://github.com/apache/storm/blob/master/pom.xml#L518. Unless
> you enable
>>> that profile, the storm-dist modules aren't in the reactor.
>>> 
>>> Den man. 12. aug. 2019 kl. 15.15 skrev Ethan Li <
> ethanopensou...@gmail.com>:
>>> 
 Just in case if anyone happens to know the answer:
 
 I created a branch
> https://github.com/apache/storm/tree/2.1.x-branch <
 

Re: [DISCUSS] Next 2.x release

[Stig Rohde Døssing]

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 :

> 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 
> wrote:
> >
> > Oops, sorry that's not right. The license plugin setup was disabled in
> > https://github.com/apache/storm/pull/3031 due to a bug in the license
> > plugin. It is added back in https://github.com/apache/storm/pull/3053,
> > where we've upgraded the plugin. Until that PR goes in, we can't easily
> > regenerate DEPENDENCY-LICENSES.
> >
> > Den tir. 13. aug. 2019 kl. 17.15 skrev Stig Rohde Døssing <
> > stigdoess...@gmail.com>:
> >
> >> There's a script that can help you do it in
> >> https://github.com/apache/storm/pull/3053. It checks the
> >> DEPENDENCY-LICENSES and LICENSE-binary contain the right dependencies,
> and
> >> prints which licenses are redundant or should be added.
> >>
> >> For DEPENDENCY-LICENSES specifically you can run "mvn
> >> license:aggregate-add-third-party@generate-and-check-licenses
> >> -Dlicense.skipAggregateAddThirdParty=false -B" in the project root. It
> >> should update the file for you.
> >>
> >> Den tir. 13. aug. 2019 kl. 17.06 skrev Ethan Li <
> ethanopensou...@gmail.com
> >>> :
> >>
> >>> Hi Stig,
> >>>
> >>> How do we update
> >>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> >>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> Is
> >>> there a command I can use? Or I just replace strings manually?
> >>>
> >>> Thanks
> >>> Ethan
> >>>
>  On Aug 12, 2019, at 3:54 PM, Ethan Li 
> >>> 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 
> >>> 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 
> >>> 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 
> >>> 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 
> >>> wrote:
> 
>  For the 2.x version lines, there are a bunch of profiles you need
> >>> to enable. This is what I use when preparing a release:
> 
>  -P dist,include-shaded-deps,rat,externals,examples
> 
>  -Taylor
> 
> > On Aug 12, 2019, at 9:27 AM, Stig Rohde Døssing <
> >>> stigdoess...@gmail.com> wrote:
> >
> > Try enabling the "dist" profile by adding "-P
> >>> dist,externals,examples" to
> > the command you're running. See
> > https://github.com/apache/storm/blob/master/pom.xml#L518. Unless
> >>> you enable
> > that profile, the storm-dist modules aren't in the reactor.
> >
> > Den man. 12. aug. 2019 kl. 15.15 skrev Ethan Li <
> >>> ethanopensou...@gmail.com>:
> >
> >> Just in case if anyone happens to know the answer:
> >>
> >> I created a branch
> >>> https://github.com/apache/storm/tree/2.1.x-branch <
> >> https://github.com/apache/storm/tree/2.1.x-branch> and ran
> >>> “mvn:prepare”
> >> and “mvn:perform”. It created two commits and created a v2.1.0
> >>> git tag. But
> >> I realized that the pom version under storm-dist was not updated
> >>> 

Re: [DISCUSS] Next 2.x release

[Ethan Li]

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  
> wrote:
> 
> Oops, sorry that's not right. The license plugin setup was disabled in
> https://github.com/apache/storm/pull/3031 due to a bug in the license
> plugin. It is added back in https://github.com/apache/storm/pull/3053,
> where we've upgraded the plugin. Until that PR goes in, we can't easily
> regenerate DEPENDENCY-LICENSES.
> 
> Den tir. 13. aug. 2019 kl. 17.15 skrev Stig Rohde Døssing <
> stigdoess...@gmail.com>:
> 
>> There's a script that can help you do it in
>> https://github.com/apache/storm/pull/3053. It checks the
>> DEPENDENCY-LICENSES and LICENSE-binary contain the right dependencies, and
>> prints which licenses are redundant or should be added.
>> 
>> For DEPENDENCY-LICENSES specifically you can run "mvn
>> license:aggregate-add-third-party@generate-and-check-licenses
>> -Dlicense.skipAggregateAddThirdParty=false -B" in the project root. It
>> should update the file for you.
>> 
>> Den tir. 13. aug. 2019 kl. 17.06 skrev Ethan Li >> :
>> 
>>> 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 
>>> 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 
>>> 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 
>>> 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 
>>> 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 
>>> wrote:
 
 For the 2.x version lines, there are a bunch of profiles you need
>>> to enable. This is what I use when preparing a release:
 
 -P dist,include-shaded-deps,rat,externals,examples
 
 -Taylor
 
> On Aug 12, 2019, at 9:27 AM, Stig Rohde Døssing <
>>> stigdoess...@gmail.com> wrote:
> 
> Try enabling the "dist" profile by adding "-P
>>> dist,externals,examples" to
> the command you're running. See
> https://github.com/apache/storm/blob/master/pom.xml#L518. Unless
>>> you enable
> that profile, the storm-dist modules aren't in the reactor.
> 
> Den man. 12. aug. 2019 kl. 15.15 skrev Ethan Li <
>>> ethanopensou...@gmail.com>:
> 
>> Just in case if anyone happens to know the answer:
>> 
>> I created a branch
>>> https://github.com/apache/storm/tree/2.1.x-branch <
>> https://github.com/apache/storm/tree/2.1.x-branch> and ran
>>> “mvn:prepare”
>> and “mvn:perform”. It created two commits and created a v2.1.0
>>> git tag. But
>> I realized that the pom version under storm-dist was not updated
>>> and it’s
>> still 2.0.1-SNAPSHOT. I checked the commits in other tags like
>> https://github.com/apache/storm/commits/v2.0.0 <
>> https://github.com/apache/storm/commits/v2.0.0> and it looks like
>> storm-dist got updated within the “mvn:prepare” step.  How do I
>>> get
>> storm-dist pom version updated with “mv:prepare”?
>> 
>> I am currently blocked on this. Any help will be appreciated.
>> 
>> Thanks,
>> Ethan
>> 
>> 
>>> On Aug 12, 2019, at 2:38 AM, Stig Rohde Døssing <
>>> 

Re: [DISCUSS] Next 2.x release

[Stig Rohde Døssing]

 Oops, sorry that's not right. The license plugin setup was disabled in
https://github.com/apache/storm/pull/3031 due to a bug in the license
plugin. It is added back in https://github.com/apache/storm/pull/3053,
where we've upgraded the plugin. Until that PR goes in, we can't easily
regenerate DEPENDENCY-LICENSES.

Den tir. 13. aug. 2019 kl. 17.15 skrev Stig Rohde Døssing <
stigdoess...@gmail.com>:

> There's a script that can help you do it in
> https://github.com/apache/storm/pull/3053. It checks the
> DEPENDENCY-LICENSES and LICENSE-binary contain the right dependencies, and
> prints which licenses are redundant or should be added.
>
> For DEPENDENCY-LICENSES specifically you can run "mvn
> license:aggregate-add-third-party@generate-and-check-licenses
> -Dlicense.skipAggregateAddThirdParty=false -B" in the project root. It
> should update the file for you.
>
> Den tir. 13. aug. 2019 kl. 17.06 skrev Ethan Li  >:
>
>> 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 
>> 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 
>> 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 
>> 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 
>> 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 
>> wrote:
>> >
>> > For the 2.x version lines, there are a bunch of profiles you need
>> to enable. This is what I use when preparing a release:
>> >
>> > -P dist,include-shaded-deps,rat,externals,examples
>> >
>> > -Taylor
>> >
>> >> On Aug 12, 2019, at 9:27 AM, Stig Rohde Døssing <
>> stigdoess...@gmail.com> wrote:
>> >>
>> >> Try enabling the "dist" profile by adding "-P
>> dist,externals,examples" to
>> >> the command you're running. See
>> >> https://github.com/apache/storm/blob/master/pom.xml#L518. Unless
>> you enable
>> >> that profile, the storm-dist modules aren't in the reactor.
>> >>
>> >> Den man. 12. aug. 2019 kl. 15.15 skrev Ethan Li <
>> ethanopensou...@gmail.com>:
>> >>
>> >>> Just in case if anyone happens to know the answer:
>> >>>
>> >>> I created a branch
>> https://github.com/apache/storm/tree/2.1.x-branch <
>> >>> https://github.com/apache/storm/tree/2.1.x-branch> and ran
>> “mvn:prepare”
>> >>> and “mvn:perform”. It created two commits and created a v2.1.0
>> git tag. But
>> >>> I realized that the pom version under storm-dist was not updated
>> and it’s
>> >>> still 2.0.1-SNAPSHOT. I checked the commits in other tags like
>> >>> https://github.com/apache/storm/commits/v2.0.0 <
>> >>> https://github.com/apache/storm/commits/v2.0.0> and it looks like
>> >>> storm-dist got updated within the “mvn:prepare” step.  How do I
>> get
>> >>> storm-dist pom version updated with “mv:prepare”?
>> >>>
>> >>> I am currently blocked on this. Any help will be appreciated.
>> >>>
>> >>> Thanks,
>> >>> Ethan
>> >>>
>> >>>
>>  On Aug 12, 2019, at 2:38 AM, Stig Rohde Døssing <
>> stigdoess...@gmail.com>
>> >>> wrote:
>> 
>>  Sounds good Ethan.
>> 
>>  Derek, I also think being clear about how long we expect to
>> support a
>>  release line is a good idea. Maybe we should do a separate
>> discuss thread
>>  on this, or if you already have a good idea for what the policy
>> should
>> >>> look
>>  like you could put it up as a PR for either the Downloads page
>> or a new
>>  page on the Storm site?
>> 
>>  Den søn. 11. aug. 2019 kl. 08.37 skrev Ethan Li <
>> >>> ethanopensou...@gmail.com>:
>> 
>> > I am doing the release following
>> > https://github.com/apache/storm/blob/master/RELEASING.md <
>> > 

Re: [DISCUSS] Next 2.x release

[Stig Rohde Døssing]

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 :

> 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  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  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 
> 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 
> 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 
> wrote:
> >
> > For the 2.x version lines, there are a bunch of profiles you need to
> enable. This is what I use when preparing a release:
> >
> > -P dist,include-shaded-deps,rat,externals,examples
> >
> > -Taylor
> >
> >> On Aug 12, 2019, at 9:27 AM, Stig Rohde Døssing <
> stigdoess...@gmail.com> wrote:
> >>
> >> Try enabling the "dist" profile by adding "-P
> dist,externals,examples" to
> >> the command you're running. See
> >> https://github.com/apache/storm/blob/master/pom.xml#L518. Unless
> you enable
> >> that profile, the storm-dist modules aren't in the reactor.
> >>
> >> Den man. 12. aug. 2019 kl. 15.15 skrev Ethan Li <
> ethanopensou...@gmail.com>:
> >>
> >>> Just in case if anyone happens to know the answer:
> >>>
> >>> I created a branch
> https://github.com/apache/storm/tree/2.1.x-branch <
> >>> https://github.com/apache/storm/tree/2.1.x-branch> and ran
> “mvn:prepare”
> >>> and “mvn:perform”. It created two commits and created a v2.1.0 git
> tag. But
> >>> I realized that the pom version under storm-dist was not updated
> and it’s
> >>> still 2.0.1-SNAPSHOT. I checked the commits in other tags like
> >>> https://github.com/apache/storm/commits/v2.0.0 <
> >>> https://github.com/apache/storm/commits/v2.0.0> and it looks like
> >>> storm-dist got updated within the “mvn:prepare” step.  How do I get
> >>> storm-dist pom version updated with “mv:prepare”?
> >>>
> >>> I am currently blocked on this. Any help will be appreciated.
> >>>
> >>> Thanks,
> >>> Ethan
> >>>
> >>>
>  On Aug 12, 2019, at 2:38 AM, Stig Rohde Døssing <
> stigdoess...@gmail.com>
> >>> wrote:
> 
>  Sounds good Ethan.
> 
>  Derek, I also think being clear about how long we expect to
> support a
>  release line is a good idea. Maybe we should do a separate
> discuss thread
>  on this, or if you already have a good idea for what the policy
> should
> >>> look
>  like you could put it up as a PR for either the Downloads page or
> a new
>  page on the Storm site?
> 
>  Den søn. 11. aug. 2019 kl. 08.37 skrev Ethan Li <
> >>> ethanopensou...@gmail.com>:
> 
> > I am doing the release following
> > https://github.com/apache/storm/blob/master/RELEASING.md <
> > https://github.com/apache/storm/blob/master/RELEASING.md> . I
> made some
> > progress but I have some questions so I just sent an email to
> Taylor.
> >
> > Please don’t merge anything to master or 2.1.x-branch for now.
> Thanks
> >
> > Best,
> > Ethan
> >
> >
> >> On Aug 9, 2019, at 4:45 PM, Ethan Li  >
> >>> wrote:
> >>
> >> Currently we have two outstanding PRs that we wanted to include
> in the
> > new release:
> >>
> >> 

Re: [DISCUSS] Next 2.x release

[Ethan Li]

Hi Stig, 

How do we update 
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  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  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  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
>>>  
>>> 
>>> 
>>> 
>>> Does anyone know where to find the updated KEYs file? Should I just use 
>>> https://www.apache.org/dist/storm/KEYS 
>>>  ?
>>> 
>>> Thanks very much
>>> 
 On Aug 12, 2019, at 9:44 AM, Ethan Li  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  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  
>> 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 
>> :
>> 
>>> 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 
 
>>> wrote:
 
 Sounds good Ethan.
 
 Derek, I also think being clear about how long we expect to support a
 release line is a good idea. Maybe we should do a separate discuss 
 thread
 on this, or if you already have a good idea for what the policy should
>>> look
 like you could put it up as a PR for either the Downloads page or a new
 page on the Storm site?
 
 Den søn. 11. aug. 2019 kl. 08.37 skrev Ethan Li <
>>> ethanopensou...@gmail.com>:
 
> I am doing the release following
> https://github.com/apache/storm/blob/master/RELEASING.md <
> https://github.com/apache/storm/blob/master/RELEASING.md> . I made 
> some
> progress but I have some questions so I just sent an email to Taylor.
> 
> Please don’t merge anything to master or 2.1.x-branch for now. Thanks
> 
> Best,
> Ethan
> 
> 
>> On Aug 9, 2019, at 4:45 PM, Ethan Li 
>>> 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 
> 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.
>> 
>> 

Re: [DISCUSS] Next 2.x release

[Ethan Li]

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  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  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
>>  
>> 
>> 
>> 
>> Does anyone know where to find the updated KEYs file? Should I just use 
>> https://www.apache.org/dist/storm/KEYS 
>>  ?
>> 
>> Thanks very much
>> 
>>> On Aug 12, 2019, at 9:44 AM, Ethan Li  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  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  
> 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 
> :
> 
>> 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 
>> wrote:
>>> 
>>> Sounds good Ethan.
>>> 
>>> Derek, I also think being clear about how long we expect to support a
>>> release line is a good idea. Maybe we should do a separate discuss 
>>> thread
>>> on this, or if you already have a good idea for what the policy should
>> look
>>> like you could put it up as a PR for either the Downloads page or a new
>>> page on the Storm site?
>>> 
>>> Den søn. 11. aug. 2019 kl. 08.37 skrev Ethan Li <
>> ethanopensou...@gmail.com>:
>>> 
 I am doing the release following
 https://github.com/apache/storm/blob/master/RELEASING.md <
 https://github.com/apache/storm/blob/master/RELEASING.md> . I made some
 progress but I have some questions so I just sent an email to Taylor.
 
 Please don’t merge anything to master or 2.1.x-branch for now. Thanks
 
 Best,
 Ethan
 
 
> On Aug 9, 2019, at 4:45 PM, Ethan Li 
>> 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 
 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 

Re: [DISCUSS] Next 2.x release

[P. Taylor Goetz]

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  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
>  
> 
> 
> 
> Does anyone know where to find the updated KEYs file? Should I just use 
> https://www.apache.org/dist/storm/KEYS 
>  ?
> 
> Thanks very much
> 
>> On Aug 12, 2019, at 9:44 AM, Ethan Li  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  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  
 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 
 :
 
> 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 
> wrote:
>> 
>> Sounds good Ethan.
>> 
>> Derek, I also think being clear about how long we expect to support a
>> release line is a good idea. Maybe we should do a separate discuss thread
>> on this, or if you already have a good idea for what the policy should
> look
>> like you could put it up as a PR for either the Downloads page or a new
>> page on the Storm site?
>> 
>> Den søn. 11. aug. 2019 kl. 08.37 skrev Ethan Li <
> ethanopensou...@gmail.com>:
>> 
>>> I am doing the release following
>>> https://github.com/apache/storm/blob/master/RELEASING.md <
>>> https://github.com/apache/storm/blob/master/RELEASING.md> . I made some
>>> progress but I have some questions so I just sent an email to Taylor.
>>> 
>>> Please don’t merge anything to master or 2.1.x-branch for now. Thanks
>>> 
>>> Best,
>>> Ethan
>>> 
>>> 
 On Aug 9, 2019, at 4:45 PM, Ethan Li 
> 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 
>>> 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 

Re: [DISCUSS] Next 2.x release

[Ethan Li]

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
 



Does anyone know where to find the updated KEYs file? Should I just use 
https://www.apache.org/dist/storm/KEYS  
?

Thanks very much

> On Aug 12, 2019, at 9:44 AM, Ethan Li  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  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  
>>> 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 :
>>> 
 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 
 wrote:
> 
> Sounds good Ethan.
> 
> Derek, I also think being clear about how long we expect to support a
> release line is a good idea. Maybe we should do a separate discuss thread
> on this, or if you already have a good idea for what the policy should
 look
> like you could put it up as a PR for either the Downloads page or a new
> page on the Storm site?
> 
> Den søn. 11. aug. 2019 kl. 08.37 skrev Ethan Li <
 ethanopensou...@gmail.com>:
> 
>> I am doing the release following
>> https://github.com/apache/storm/blob/master/RELEASING.md <
>> https://github.com/apache/storm/blob/master/RELEASING.md> . I made some
>> progress but I have some questions so I just sent an email to Taylor.
>> 
>> Please don’t merge anything to master or 2.1.x-branch for now. Thanks
>> 
>> Best,
>> Ethan
>> 
>> 
>>> On Aug 9, 2019, at 4:45 PM, Ethan Li 
 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 
>> 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 

Re: [DISCUSS] Next 2.x release

[Ethan Li]

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  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  
>> 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 :
>> 
>>> 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 
>>> wrote:
 
 Sounds good Ethan.
 
 Derek, I also think being clear about how long we expect to support a
 release line is a good idea. Maybe we should do a separate discuss thread
 on this, or if you already have a good idea for what the policy should
>>> look
 like you could put it up as a PR for either the Downloads page or a new
 page on the Storm site?
 
 Den søn. 11. aug. 2019 kl. 08.37 skrev Ethan Li <
>>> ethanopensou...@gmail.com>:
 
> I am doing the release following
> https://github.com/apache/storm/blob/master/RELEASING.md <
> https://github.com/apache/storm/blob/master/RELEASING.md> . I made some
> progress but I have some questions so I just sent an email to Taylor.
> 
> Please don’t merge anything to master or 2.1.x-branch for now. Thanks
> 
> Best,
> Ethan
> 
> 
>> On Aug 9, 2019, at 4:45 PM, Ethan Li 
>>> 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 
> 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 

Re: [DISCUSS] Next 2.x release

[P. Taylor Goetz]

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  
> 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 :
> 
>> 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 
>> wrote:
>>> 
>>> Sounds good Ethan.
>>> 
>>> Derek, I also think being clear about how long we expect to support a
>>> release line is a good idea. Maybe we should do a separate discuss thread
>>> on this, or if you already have a good idea for what the policy should
>> look
>>> like you could put it up as a PR for either the Downloads page or a new
>>> page on the Storm site?
>>> 
>>> Den søn. 11. aug. 2019 kl. 08.37 skrev Ethan Li <
>> ethanopensou...@gmail.com>:
>>> 
 I am doing the release following
 https://github.com/apache/storm/blob/master/RELEASING.md <
 https://github.com/apache/storm/blob/master/RELEASING.md> . I made some
 progress but I have some questions so I just sent an email to Taylor.
 
 Please don’t merge anything to master or 2.1.x-branch for now. Thanks
 
 Best,
 Ethan
 
 
> On Aug 9, 2019, at 4:45 PM, Ethan Li 
>> 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 
 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 <
 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 

Re: [DISCUSS] Next 2.x release

[Stig Rohde Døssing]

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 :

> 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 
> wrote:
> >
> > Sounds good Ethan.
> >
> > Derek, I also think being clear about how long we expect to support a
> > release line is a good idea. Maybe we should do a separate discuss thread
> > on this, or if you already have a good idea for what the policy should
> look
> > like you could put it up as a PR for either the Downloads page or a new
> > page on the Storm site?
> >
> > Den søn. 11. aug. 2019 kl. 08.37 skrev Ethan Li <
> ethanopensou...@gmail.com>:
> >
> >> I am doing the release following
> >> https://github.com/apache/storm/blob/master/RELEASING.md <
> >> https://github.com/apache/storm/blob/master/RELEASING.md> . I made some
> >> progress but I have some questions so I just sent an email to Taylor.
> >>
> >> Please don’t merge anything to master or 2.1.x-branch for now. Thanks
> >>
> >> Best,
> >> Ethan
> >>
> >>
> >>> On Aug 9, 2019, at 4:45 PM, Ethan Li 
> 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 
> >> 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 <
> >> 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 

Re: [DISCUSS] Next 2.x release

[Ethan Li]

Just in case if anyone happens to know the answer:

I created a 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 
 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  
> 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 :
> 
>> 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  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 
>> 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 <
>> 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. 

Re: [DISCUSS] Next 2.x release

[Stig Rohde Døssing]

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 :

> 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  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 
> 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 <
> 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  >:
> >
> >> What do we think about defining Long-Term 

Re: [DISCUSS] Next 2.x release

[Ethan Li]

I am doing the release following 
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  wrote:
> 
> Currently we have two outstanding PRs that we wanted to include in the new 
> release:
> 
> https://github.com/apache/storm/pull/3096 
>  (Travis has some issues  
> connecting to repository.apache.org  recently. 
> Travis build fails consistently)
> 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 > > 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 >>> > 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  >:
> 
>> 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 

Re: [DISCUSS] Next 2.x release

[Ethan Li]

Currently we have two outstanding PRs that we wanted to include in the new 
release:

https://github.com/apache/storm/pull/3096 
 (Travis has some issues  connecting 
to repository.apache.org  recently. Travis build 
fails consistently)
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  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  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 :
 
> 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 

Re: [DISCUSS] Next 2.x release

[Derek Dagit]

> 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  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 :
> >>
> >>> 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 
> >>> wrote:
> >
> > Yes thanks.
> >
> >> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
> >>> stigdoess...@gmail.com> wrote:
> >>
> >> Sounds great. Remember to add your key to
> >> https://dist.apache.org/repos/dist/release/storm/KEYS, you should be
> >>> able
> >> to update it 

Re: [DISCUSS] Next 2.x release

[Ethan Li]

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  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 :
>> 
>>> 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 
>>> wrote:
> 
> Yes thanks.
> 
>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
>>> stigdoess...@gmail.com> wrote:
>> 
>> Sounds great. Remember to add your key to
>> https://dist.apache.org/repos/dist/release/storm/KEYS, you should be
>>> able
>> to update it with an SVN client. See also
>> https://www.apache.org/dev/openpgp.html#update.
>> 
>> Den ons. 7. aug. 2019 kl. 15.05 skrev Ethan Li <
>>> ethanopensou...@gmail.com>:
>> 
>>> I got my pgp key signed by Bryan W. Call >> bc...@apache.org>> (Thanks to him).
>>> 
>>> My pgp key:
>>> 
>>> http://pgp.surfnet.nl/pks/lookup?op=vindex=on=0xA4A672F11B5050C8
>>> <
>>> 
>>> http://pgp.surfnet.nl/pks/lookup?op=vindex=on=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 

Re: [DISCUSS] Next 2.x release

[Ethan Li]

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/ ).  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  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 

Re: [DISCUSS] Next 2.x release

[Derek Dagit]

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 :
> 
> > 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 
> > wrote:
> > > >
> > > > Yes thanks.
> > > >
> > > >> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
> > stigdoess...@gmail.com> wrote:
> > > >>
> > > >> Sounds great. Remember to add your key to
> > > >> https://dist.apache.org/repos/dist/release/storm/KEYS, you should be
> > able
> > > >> to update it with an SVN client. See also
> > > >> https://www.apache.org/dev/openpgp.html#update.
> > > >>
> > > >> Den ons. 7. aug. 2019 kl. 15.05 skrev Ethan Li <
> > ethanopensou...@gmail.com>:
> > > >>
> > > >>> I got my pgp key signed by Bryan W. Call  > > >>> bc...@apache.org>> (Thanks to him).
> > > >>>
> > > >>> My pgp key:
> > > >>>
> > http://pgp.surfnet.nl/pks/lookup?op=vindex=on=0xA4A672F11B5050C8
> > > >>> <
> > > >>>
> > http://pgp.surfnet.nl/pks/lookup?op=vindex=on=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>
> > > 

Re: [DISCUSS] Next 2.x release

[Stig Rohde Døssing]

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 :

> 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 
> wrote:
> > >
> > > Yes thanks.
> > >
> > >> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
> stigdoess...@gmail.com> wrote:
> > >>
> > >> Sounds great. Remember to add your key to
> > >> https://dist.apache.org/repos/dist/release/storm/KEYS, you should be
> able
> > >> to update it with an SVN client. See also
> > >> https://www.apache.org/dev/openpgp.html#update.
> > >>
> > >> Den ons. 7. aug. 2019 kl. 15.05 skrev Ethan Li <
> ethanopensou...@gmail.com>:
> > >>
> > >>> I got my pgp key signed by Bryan W. Call  > >>> bc...@apache.org>> (Thanks to him).
> > >>>
> > >>> My pgp key:
> > >>>
> 

Re: [DISCUSS] Next 2.x release

[Derek Dagit]

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  wrote:
> >
> > Yes thanks.
> >
> >> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing  
> >> 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 :
> >>
> >>> I got my pgp key signed by Bryan W. Call  >>> bc...@apache.org>> (Thanks to him).
> >>>
> >>> My pgp key:
> >>> http://pgp.surfnet.nl/pks/lookup?op=vindex=on=0xA4A672F11B5050C8
> >>> <
> >>> http://pgp.surfnet.nl/pks/lookup?op=vindex=on=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 
> >>> wrote:
> 
>  Thanks Ethan, yes 2.1.0 makes sense.
> 
>  Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
> >>> ethanopensou...@gmail.com>:
> 
> > It’s a good point. I will start a discussion thread for it.
> >
> >
> > For the new release, I went through the list:
> >
> >>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1
> > <
> >
> >>> https://issues.apache.org/jira/issues/?jql=project%20=%20STORM%20AND%20fixVersion%20=%202.0.1
> >>
> >
> > We introduced some new functionalities, including
> > https://issues.apache.org/jira/browse/STORM-2720 <
> > https://issues.apache.org/jira/browse/STORM-2720>
> > https://issues.apache.org/jira/browse/STORM-3412 <
> > https://issues.apache.org/jira/browse/STORM-3412>
> > https://issues.apache.org/jira/browse/STORM-3411 <
> > https://issues.apache.org/jira/browse/STORM-3411>
> > https://issues.apache.org/jira/browse/STORM-3442 <
> > https://issues.apache.org/jira/browse/STORM-3442>
> > https://issues.apache.org/jira/browse/STORM-3396 <
> > https://issues.apache.org/jira/browse/STORM-3396>
> > https://issues.apache.org/jira/browse/STORM-3392 <
> > https://issues.apache.org/jira/browse/STORM-3392>
> > https://issues.apache.org/jira/browse/STORM-3395 <
> > https://issues.apache.org/jira/browse/STORM-3395>
> >
> > So I think we should release 2.1.0 rather than 2.0.1.
> >
> > There are a few pull requests we may want to review before the next
> > release:
> >
> > https://github.com/apache/storm/pull/3094 <
> > https://github.com/apache/storm/pull/3094>
> > https://github.com/apache/storm/pull/2990 <
> > https://github.com/apache/storm/pull/2990>
> > https://github.com/apache/storm/pull/2878 <
> > https://github.com/apache/storm/pull/2878>
> >
> >
> > Thanks
> > Ethan
> >
> >
> >> On Jul 29, 2019, at 10:11 AM, Hugo Louro  wrote:
> >>
> >> +1
> 

Re: [DISCUSS] Next 2.x release

[Ethan Li]

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  wrote:
> 
> Yes thanks. 
> 
>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing  
>> 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 :
>> 
>>> I got my pgp key signed by Bryan W. Call >> bc...@apache.org>> (Thanks to him).
>>> 
>>> My pgp key:
>>> http://pgp.surfnet.nl/pks/lookup?op=vindex=on=0xA4A672F11B5050C8
>>> <
>>> http://pgp.surfnet.nl/pks/lookup?op=vindex=on=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 
>>> wrote:
 
 Thanks Ethan, yes 2.1.0 makes sense.
 
 Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
>>> ethanopensou...@gmail.com>:
 
> It’s a good point. I will start a discussion thread for it.
> 
> 
> For the new release, I went through the list:
> 
>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1
> <
> 
>>> https://issues.apache.org/jira/issues/?jql=project%20=%20STORM%20AND%20fixVersion%20=%202.0.1
>> 
> 
> We introduced some new functionalities, including
> https://issues.apache.org/jira/browse/STORM-2720 <
> https://issues.apache.org/jira/browse/STORM-2720>
> https://issues.apache.org/jira/browse/STORM-3412 <
> https://issues.apache.org/jira/browse/STORM-3412>
> https://issues.apache.org/jira/browse/STORM-3411 <
> https://issues.apache.org/jira/browse/STORM-3411>
> https://issues.apache.org/jira/browse/STORM-3442 <
> https://issues.apache.org/jira/browse/STORM-3442>
> https://issues.apache.org/jira/browse/STORM-3396 <
> https://issues.apache.org/jira/browse/STORM-3396>
> https://issues.apache.org/jira/browse/STORM-3392 <
> https://issues.apache.org/jira/browse/STORM-3392>
> https://issues.apache.org/jira/browse/STORM-3395 <
> https://issues.apache.org/jira/browse/STORM-3395>
> 
> So I think we should release 2.1.0 rather than 2.0.1.
> 
> There are a few pull requests we may want to review before the next
> release:
> 
> https://github.com/apache/storm/pull/3094 <
> https://github.com/apache/storm/pull/3094>
> https://github.com/apache/storm/pull/2990 <
> https://github.com/apache/storm/pull/2990>
> https://github.com/apache/storm/pull/2878 <
> https://github.com/apache/storm/pull/2878>
> 
> 
> Thanks
> Ethan
> 
> 
>> On Jul 29, 2019, at 10:11 AM, Hugo Louro  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 
> wrote:
>> 
>>> Thanks Stig. I will look into it.
>>> 
 On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
> stigdoess...@gmail.com>
>>> wrote:
 
 I think ideally we've been trying for semver, but it's been pretty
> loose,
 e.g. there were breaking changes in one of the 1.2.x releases for
 storm-kafka-client. I don't know what rules we've actually been
>>> using,
> if

Re: [DISCUSS] Next 2.x release

[Ethan Li]

Yes thanks. 

> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing  
> 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 :
> 
>> I got my pgp key signed by Bryan W. Call > bc...@apache.org>> (Thanks to him).
>> 
>> My pgp key:
>> http://pgp.surfnet.nl/pks/lookup?op=vindex=on=0xA4A672F11B5050C8
>> <
>> http://pgp.surfnet.nl/pks/lookup?op=vindex=on=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 
>> wrote:
>>> 
>>> Thanks Ethan, yes 2.1.0 makes sense.
>>> 
>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
>> ethanopensou...@gmail.com>:
>>> 
 It’s a good point. I will start a discussion thread for it.
 
 
 For the new release, I went through the list:
 
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1
 <
 
>> https://issues.apache.org/jira/issues/?jql=project%20=%20STORM%20AND%20fixVersion%20=%202.0.1
> 
 
 We introduced some new functionalities, including
 https://issues.apache.org/jira/browse/STORM-2720 <
 https://issues.apache.org/jira/browse/STORM-2720>
 https://issues.apache.org/jira/browse/STORM-3412 <
 https://issues.apache.org/jira/browse/STORM-3412>
 https://issues.apache.org/jira/browse/STORM-3411 <
 https://issues.apache.org/jira/browse/STORM-3411>
 https://issues.apache.org/jira/browse/STORM-3442 <
 https://issues.apache.org/jira/browse/STORM-3442>
 https://issues.apache.org/jira/browse/STORM-3396 <
 https://issues.apache.org/jira/browse/STORM-3396>
 https://issues.apache.org/jira/browse/STORM-3392 <
 https://issues.apache.org/jira/browse/STORM-3392>
 https://issues.apache.org/jira/browse/STORM-3395 <
 https://issues.apache.org/jira/browse/STORM-3395>
 
 So I think we should release 2.1.0 rather than 2.0.1.
 
 There are a few pull requests we may want to review before the next
 release:
 
 https://github.com/apache/storm/pull/3094 <
 https://github.com/apache/storm/pull/3094>
 https://github.com/apache/storm/pull/2990 <
 https://github.com/apache/storm/pull/2990>
 https://github.com/apache/storm/pull/2878 <
 https://github.com/apache/storm/pull/2878>
 
 
 Thanks
 Ethan
 
 
> On Jul 29, 2019, at 10:11 AM, Hugo Louro  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 
 wrote:
> 
>> Thanks Stig. I will look into it.
>> 
>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
 stigdoess...@gmail.com>
>> wrote:
>>> 
>>> I think ideally we've been trying for semver, but it's been pretty
 loose,
>>> e.g. there were breaking changes in one of the 1.2.x releases for
>>> storm-kafka-client. I don't know what rules we've actually been
>> using,
 if
>>> any.
>>> 
>>> Semver for binary compatibility would probably be a good rule of
>> thumb.
>>> 
>>> Den fre. 26. jul. 2019 kl. 20.01 skrev Ethan Li <
>> ethanopensou...@gmail.com>:
>>> 
 
 Stig,
 
 Do you know what’s the versioning standard we have been following
>> (to
 determine a 2.0.1 release or 2.1.0 release) ?
 
 
> On Jul 26, 2019, at 12:26 PM, Stig Rohde Døssing <
>> stigdoess...@gmail.com>
 wrote:
> 
> Sounds great, thanks Ethan.
> 
> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
 ethanopensou...@gmail.com>:
> 
>> It’s good idea to do more frequent release. I can run the next
>> release.
>> 
>> I will take a look at both PRs. Other than that, I think we should
>> also
>> get https://github.com/apache/storm/pull/3093 <
>> https://github.com/apache/storm/pull/3093> 

Re: [DISCUSS] Next 2.x release

[Stig Rohde Døssing]

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 :

> I got my pgp key signed by Bryan W. Call  bc...@apache.org>> (Thanks to him).
>
> My pgp key:
> http://pgp.surfnet.nl/pks/lookup?op=vindex=on=0xA4A672F11B5050C8
> <
> http://pgp.surfnet.nl/pks/lookup?op=vindex=on=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 
> wrote:
> >
> > Thanks Ethan, yes 2.1.0 makes sense.
> >
> > Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
> ethanopensou...@gmail.com>:
> >
> >> It’s a good point. I will start a discussion thread for it.
> >>
> >>
> >> For the new release, I went through the list:
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1
> >> <
> >>
> https://issues.apache.org/jira/issues/?jql=project%20=%20STORM%20AND%20fixVersion%20=%202.0.1
> >>>
> >>
> >> We introduced some new functionalities, including
> >> https://issues.apache.org/jira/browse/STORM-2720 <
> >> https://issues.apache.org/jira/browse/STORM-2720>
> >> https://issues.apache.org/jira/browse/STORM-3412 <
> >> https://issues.apache.org/jira/browse/STORM-3412>
> >> https://issues.apache.org/jira/browse/STORM-3411 <
> >> https://issues.apache.org/jira/browse/STORM-3411>
> >> https://issues.apache.org/jira/browse/STORM-3442 <
> >> https://issues.apache.org/jira/browse/STORM-3442>
> >> https://issues.apache.org/jira/browse/STORM-3396 <
> >> https://issues.apache.org/jira/browse/STORM-3396>
> >> https://issues.apache.org/jira/browse/STORM-3392 <
> >> https://issues.apache.org/jira/browse/STORM-3392>
> >> https://issues.apache.org/jira/browse/STORM-3395 <
> >> https://issues.apache.org/jira/browse/STORM-3395>
> >>
> >> So I think we should release 2.1.0 rather than 2.0.1.
> >>
> >> There are a few pull requests we may want to review before the next
> >> release:
> >>
> >> https://github.com/apache/storm/pull/3094 <
> >> https://github.com/apache/storm/pull/3094>
> >> https://github.com/apache/storm/pull/2990 <
> >> https://github.com/apache/storm/pull/2990>
> >> https://github.com/apache/storm/pull/2878 <
> >> https://github.com/apache/storm/pull/2878>
> >>
> >>
> >> Thanks
> >> Ethan
> >>
> >>
> >>> On Jul 29, 2019, at 10:11 AM, Hugo Louro  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 
> >> wrote:
> >>>
>  Thanks Stig. I will look into it.
> 
> > On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
> >> stigdoess...@gmail.com>
>  wrote:
> >
> > I think ideally we've been trying for semver, but it's been pretty
> >> loose,
> > e.g. there were breaking changes in one of the 1.2.x releases for
> > storm-kafka-client. I don't know what rules we've actually been
> using,
> >> if
> > any.
> >
> > Semver for binary compatibility would probably be a good rule of
> thumb.
> >
> > Den fre. 26. jul. 2019 kl. 20.01 skrev Ethan Li <
>  ethanopensou...@gmail.com>:
> >
> >>
> >> Stig,
> >>
> >> Do you know what’s the versioning standard we have been following
> (to
> >> determine a 2.0.1 release or 2.1.0 release) ?
> >>
> >>
> >>> On Jul 26, 2019, at 12:26 PM, Stig Rohde Døssing <
>  stigdoess...@gmail.com>
> >> wrote:
> >>>
> >>> Sounds great, thanks Ethan.
> >>>
> >>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
> >> ethanopensou...@gmail.com>:
> >>>
>  It’s good idea to do more frequent release. I can run the next
>  release.
> 
>  I will take a look at both PRs. Other than that, I think we should
>  also
>  get https://github.com/apache/storm/pull/3093 <
>  https://github.com/apache/storm/pull/3093>  in the new release.
> 
> 
> > On Jul 26, 2019, at 11:58 AM, Stig Rohde Døssing <
> >> stigdoess...@gmail.com>
>  wrote:
> >
> 

Re: [DISCUSS] Next 2.x release

[Ethan Li]

I got my pgp key signed by Bryan W. Call mailto:bc...@apache.org>> (Thanks to him).  

My pgp key: 
http://pgp.surfnet.nl/pks/lookup?op=vindex=on=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/3096 

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  wrote:
> 
> Thanks Ethan, yes 2.1.0 makes sense.
> 
> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li :
> 
>> 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  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 
>> wrote:
>>> 
 Thanks Stig. I will look into it.
 
> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
>> stigdoess...@gmail.com>
 wrote:
> 
> I think ideally we've been trying for semver, but it's been pretty
>> loose,
> e.g. there were breaking changes in one of the 1.2.x releases for
> storm-kafka-client. I don't know what rules we've actually been using,
>> if
> any.
> 
> Semver for binary compatibility would probably be a good rule of thumb.
> 
> Den fre. 26. jul. 2019 kl. 20.01 skrev Ethan Li <
 ethanopensou...@gmail.com>:
> 
>> 
>> Stig,
>> 
>> Do you know what’s the versioning standard we have been following (to
>> determine a 2.0.1 release or 2.1.0 release) ?
>> 
>> 
>>> On Jul 26, 2019, at 12:26 PM, Stig Rohde Døssing <
 stigdoess...@gmail.com>
>> wrote:
>>> 
>>> Sounds great, thanks Ethan.
>>> 
>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
>> ethanopensou...@gmail.com>:
>>> 
 It’s good idea to do more frequent release. I can run the next
 release.
 
 I will take a look at both PRs. Other than that, I think we should
 also
 get https://github.com/apache/storm/pull/3093 <
 https://github.com/apache/storm/pull/3093>  in the new release.
 
 
> On Jul 26, 2019, at 11:58 AM, Stig Rohde Døssing <
>> stigdoess...@gmail.com>
 wrote:
> 
> Hi,
> 
> I think we've talked about more frequent releases before. Releasing
 new
> versions every few months means people don't have to wait long for
>> fixes
 to
> get out, and smaller releases are probably also easier for users to
 get
 to
> grips with (the fix list for 2.0.0 is enormous).
> 
> With that in mind, I think we should start looking at the next 2.x
 release
> (2.0.1 or 2.1.0?), since it's been a couple 

Re: [DISCUSS] Next 2.x release

[Stig Rohde Døssing]

Thanks Ethan, yes 2.1.0 makes sense.

Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li :

> 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  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 
> wrote:
> >
> >> Thanks Stig. I will look into it.
> >>
> >>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing <
> stigdoess...@gmail.com>
> >> wrote:
> >>>
> >>> I think ideally we've been trying for semver, but it's been pretty
> loose,
> >>> e.g. there were breaking changes in one of the 1.2.x releases for
> >>> storm-kafka-client. I don't know what rules we've actually been using,
> if
> >>> any.
> >>>
> >>> Semver for binary compatibility would probably be a good rule of thumb.
> >>>
> >>> Den fre. 26. jul. 2019 kl. 20.01 skrev Ethan Li <
> >> ethanopensou...@gmail.com>:
> >>>
> 
>  Stig,
> 
>  Do you know what’s the versioning standard we have been following (to
>  determine a 2.0.1 release or 2.1.0 release) ?
> 
> 
> > On Jul 26, 2019, at 12:26 PM, Stig Rohde Døssing <
> >> stigdoess...@gmail.com>
>  wrote:
> >
> > Sounds great, thanks Ethan.
> >
> > Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
>  ethanopensou...@gmail.com>:
> >
> >> It’s good idea to do more frequent release. I can run the next
> >> release.
> >>
> >> I will take a look at both PRs. Other than that, I think we should
> >> also
> >> get https://github.com/apache/storm/pull/3093 <
> >> https://github.com/apache/storm/pull/3093>  in the new release.
> >>
> >>
> >>> On Jul 26, 2019, at 11:58 AM, Stig Rohde Døssing <
>  stigdoess...@gmail.com>
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I think we've talked about more frequent releases before. Releasing
> >> new
> >>> versions every few months means people don't have to wait long for
>  fixes
> >> to
> >>> get out, and smaller releases are probably also easier for users to
> >> get
> >> to
> >>> grips with (the fix list for 2.0.0 is enormous).
> >>>
> >>> With that in mind, I think we should start looking at the next 2.x
> >> release
> >>> (2.0.1 or 2.1.0?), since it's been a couple of months since 2.0.0
> >> released.
> >>> The fix list would be
> >>>
> >>
> 
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1
> >>> .
> >>>
> >>> Govind and Ethan have offered to run the next release, and help
>  validate
> >>> our release process guidelines. Would one of you have time to work
> >> on a
> >>> release in the near future?
> >>>
> >>> It would be good to take a look at currently open PRs and decide
> >> which
>  we
> >>> feel need to get merged before the next release.
> >>>
> >>> I would like to see at least
> >> https://github.com/apache/storm/pull/2990
> >>> merged
> >>>
> >>> https://github.com/apache/storm/pull/2878 seems like it's close to
> >> be
> >>> mergeable too?
> 

Re: [DISCUSS] Next 2.x release

[Ethan Li]

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
 


We introduced some new functionalities, including 
https://issues.apache.org/jira/browse/STORM-2720 

https://issues.apache.org/jira/browse/STORM-3412 
 
https://issues.apache.org/jira/browse/STORM-3411 
   
https://issues.apache.org/jira/browse/STORM-3442 
  
https://issues.apache.org/jira/browse/STORM-3396 

https://issues.apache.org/jira/browse/STORM-3392 

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/2990 

https://github.com/apache/storm/pull/2878 



Thanks
Ethan


> On Jul 29, 2019, at 10:11 AM, Hugo Louro  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  wrote:
> 
>> Thanks Stig. I will look into it.
>> 
>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing 
>> wrote:
>>> 
>>> I think ideally we've been trying for semver, but it's been pretty loose,
>>> e.g. there were breaking changes in one of the 1.2.x releases for
>>> storm-kafka-client. I don't know what rules we've actually been using, if
>>> any.
>>> 
>>> Semver for binary compatibility would probably be a good rule of thumb.
>>> 
>>> Den fre. 26. jul. 2019 kl. 20.01 skrev Ethan Li <
>> ethanopensou...@gmail.com>:
>>> 
 
 Stig,
 
 Do you know what’s the versioning standard we have been following (to
 determine a 2.0.1 release or 2.1.0 release) ?
 
 
> On Jul 26, 2019, at 12:26 PM, Stig Rohde Døssing <
>> stigdoess...@gmail.com>
 wrote:
> 
> Sounds great, thanks Ethan.
> 
> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
 ethanopensou...@gmail.com>:
> 
>> It’s good idea to do more frequent release. I can run the next
>> release.
>> 
>> I will take a look at both PRs. Other than that, I think we should
>> also
>> get https://github.com/apache/storm/pull/3093 <
>> https://github.com/apache/storm/pull/3093>  in the new release.
>> 
>> 
>>> On Jul 26, 2019, at 11:58 AM, Stig Rohde Døssing <
 stigdoess...@gmail.com>
>> wrote:
>>> 
>>> Hi,
>>> 
>>> I think we've talked about more frequent releases before. Releasing
>> new
>>> versions every few months means people don't have to wait long for
 fixes
>> to
>>> get out, and smaller releases are probably also easier for users to
>> get
>> to
>>> grips with (the fix list for 2.0.0 is enormous).
>>> 
>>> With that in mind, I think we should start looking at the next 2.x
>> release
>>> (2.0.1 or 2.1.0?), since it's been a couple of months since 2.0.0
>> released.
>>> The fix list would be
>>> 
>> 
 
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1
>>> .
>>> 
>>> Govind and Ethan have offered to run the next release, and help
 validate
>>> our release process guidelines. Would one of you have time to work
>> on a
>>> release in the near future?
>>> 
>>> It would be good to take a look at currently open PRs and decide
>> which
 we
>>> feel need to get merged before the next release.
>>> 
>>> I would like to see at least
>> https://github.com/apache/storm/pull/2990
>>> merged
>>> 
>>> https://github.com/apache/storm/pull/2878 seems like it's close to
>> be
>>> mergeable too?
>> 
>> 
 
 
>> 
>> 

Re: [DISCUSS] Next 2.x release

[Hugo Louro]

+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  wrote:

> Thanks Stig. I will look into it.
>
> > On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing 
> wrote:
> >
> > I think ideally we've been trying for semver, but it's been pretty loose,
> > e.g. there were breaking changes in one of the 1.2.x releases for
> > storm-kafka-client. I don't know what rules we've actually been using, if
> > any.
> >
> > Semver for binary compatibility would probably be a good rule of thumb.
> >
> > Den fre. 26. jul. 2019 kl. 20.01 skrev Ethan Li <
> ethanopensou...@gmail.com>:
> >
> >>
> >> Stig,
> >>
> >> Do you know what’s the versioning standard we have been following (to
> >> determine a 2.0.1 release or 2.1.0 release) ?
> >>
> >>
> >>> On Jul 26, 2019, at 12:26 PM, Stig Rohde Døssing <
> stigdoess...@gmail.com>
> >> wrote:
> >>>
> >>> Sounds great, thanks Ethan.
> >>>
> >>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
> >> ethanopensou...@gmail.com>:
> >>>
>  It’s good idea to do more frequent release. I can run the next
> release.
> 
>  I will take a look at both PRs. Other than that, I think we should
> also
>  get https://github.com/apache/storm/pull/3093 <
>  https://github.com/apache/storm/pull/3093>  in the new release.
> 
> 
> > On Jul 26, 2019, at 11:58 AM, Stig Rohde Døssing <
> >> stigdoess...@gmail.com>
>  wrote:
> >
> > Hi,
> >
> > I think we've talked about more frequent releases before. Releasing
> new
> > versions every few months means people don't have to wait long for
> >> fixes
>  to
> > get out, and smaller releases are probably also easier for users to
> get
>  to
> > grips with (the fix list for 2.0.0 is enormous).
> >
> > With that in mind, I think we should start looking at the next 2.x
>  release
> > (2.0.1 or 2.1.0?), since it's been a couple of months since 2.0.0
>  released.
> > The fix list would be
> >
> 
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1
> > .
> >
> > Govind and Ethan have offered to run the next release, and help
> >> validate
> > our release process guidelines. Would one of you have time to work
> on a
> > release in the near future?
> >
> > It would be good to take a look at currently open PRs and decide
> which
> >> we
> > feel need to get merged before the next release.
> >
> > I would like to see at least
> https://github.com/apache/storm/pull/2990
> > merged
> >
> > https://github.com/apache/storm/pull/2878 seems like it's close to
> be
> > mergeable too?
> 
> 
> >>
> >>
>
>

Re: [DISCUSS] Next 2.x release

[Ethan Li]

Thanks Stig. I will look into it.

> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing  
> 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 :
> 
>> 
>> 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 
>> wrote:
>>> 
>>> Sounds great, thanks Ethan.
>>> 
>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
>> ethanopensou...@gmail.com>:
>>> 
 It’s good idea to do more frequent release. I can run the next release.
 
 I will take a look at both PRs. Other than that, I think we should also
 get https://github.com/apache/storm/pull/3093 <
 https://github.com/apache/storm/pull/3093>  in the new release.
 
 
> On Jul 26, 2019, at 11:58 AM, Stig Rohde Døssing <
>> stigdoess...@gmail.com>
 wrote:
> 
> Hi,
> 
> I think we've talked about more frequent releases before. Releasing new
> versions every few months means people don't have to wait long for
>> fixes
 to
> get out, and smaller releases are probably also easier for users to get
 to
> grips with (the fix list for 2.0.0 is enormous).
> 
> With that in mind, I think we should start looking at the next 2.x
 release
> (2.0.1 or 2.1.0?), since it's been a couple of months since 2.0.0
 released.
> The fix list would be
> 
 
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1
> .
> 
> Govind and Ethan have offered to run the next release, and help
>> validate
> our release process guidelines. Would one of you have time to work on a
> release in the near future?
> 
> It would be good to take a look at currently open PRs and decide which
>> we
> feel need to get merged before the next release.
> 
> I would like to see at least https://github.com/apache/storm/pull/2990
> merged
> 
> https://github.com/apache/storm/pull/2878 seems like it's close to be
> mergeable too?
 
 
>> 
>> 

Re: [DISCUSS] Next 2.x release

[Stig Rohde Døssing]

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 :

>
> 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 
> wrote:
> >
> > Sounds great, thanks Ethan.
> >
> > Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li <
> ethanopensou...@gmail.com>:
> >
> >> It’s good idea to do more frequent release. I can run the next release.
> >>
> >> I will take a look at both PRs. Other than that, I think we should also
> >> get https://github.com/apache/storm/pull/3093 <
> >> https://github.com/apache/storm/pull/3093>  in the new release.
> >>
> >>
> >>> On Jul 26, 2019, at 11:58 AM, Stig Rohde Døssing <
> stigdoess...@gmail.com>
> >> wrote:
> >>>
> >>> Hi,
> >>>
> >>> I think we've talked about more frequent releases before. Releasing new
> >>> versions every few months means people don't have to wait long for
> fixes
> >> to
> >>> get out, and smaller releases are probably also easier for users to get
> >> to
> >>> grips with (the fix list for 2.0.0 is enormous).
> >>>
> >>> With that in mind, I think we should start looking at the next 2.x
> >> release
> >>> (2.0.1 or 2.1.0?), since it's been a couple of months since 2.0.0
> >> released.
> >>> The fix list would be
> >>>
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1
> >>> .
> >>>
> >>> Govind and Ethan have offered to run the next release, and help
> validate
> >>> our release process guidelines. Would one of you have time to work on a
> >>> release in the near future?
> >>>
> >>> It would be good to take a look at currently open PRs and decide which
> we
> >>> feel need to get merged before the next release.
> >>>
> >>> I would like to see at least https://github.com/apache/storm/pull/2990
> >>> merged
> >>>
> >>> https://github.com/apache/storm/pull/2878 seems like it's close to be
> >>> mergeable too?
> >>
> >>
>
>

Re: [DISCUSS] Next 2.x release

[Ethan Li]

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  
> wrote:
> 
> Sounds great, thanks Ethan.
> 
> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li :
> 
>> 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 
>> 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

[Stig Rohde Døssing]

Sounds great, thanks Ethan.

Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li :

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

[Ethan Li]

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 
  in the new release. 


> On Jul 26, 2019, at 11:58 AM, Stig Rohde Døssing  
> 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?

[DISCUSS] Next 2.x release

[Stig Rohde Døssing]

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?