Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

> 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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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:

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

> 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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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:

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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.

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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.

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

Thanks Ethan, yes 2.1.0 makes sense. Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li : > It’s a good point. I will start a discussion thread for it. > > > For the new release, I went through the list: >

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

+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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

Re: [DISCUSS] Next 2.x release

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

[DISCUSS] Next 2.x release

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