storm-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stig Rohde Døssing <stigdoess...@gmail.com>
Subject Re: [DISCUSS] Next 2.x release
Date Mon, 19 Aug 2019 18:24:03 GMT
Ok, that makes sense. I still don't understand the need for 2.1-SNAPSHOT?

If we branch off 2.1.x-branch and then roll master to 2.2.0-SNAPSHOT
immediately, we can merge any commits into master and mark them in Jira
with fix version 2.2.0. If we then get a bugfix that needs to go in e.g.
2.1.1, we can merge it to master and cherry pick the commit back to
2.1.x-branch, and update the fix version to both 2.2.0 and 2.1.1. This is
basically similar to how it worked for the 1.x-branch branches.

Why do we need 2.1-SNAPSHOT?

Den man. 19. aug. 2019 kl. 20.03 skrev Ethan Li <ethanopensource@gmail.com>:

> We don’t create 2.1.0 branch.
>
> I was thinking (and have been doing) about creating a 2.1.x-branch before
> doing any thing release related.  Then we use 2.1.x-branch to release
> 2.1.0, and 2.1.1, etc.
>
> When we create a 2.1.x-branch,  we move master to 2.2.x-branch. It’s a
> little different than what we did in the past. But it makes more sense as
> it follows semantic versioning more strictly.
>
>
>
> > On Aug 19, 2019, at 12:53 PM, Stig Rohde Døssing <stigdoessing@gmail.com>
> wrote:
> >
> > I would be fine with just freezing (non-critical) merges during the
> > release process. These mails are public, so it's easy for anyone to see
> > whether a release is in progress.
> >
> > If we want to do merges while releases are going on, I think your
> proposal
> > of using a release branch is fine. I'm not sure I understand why we need
> > the 2.1-SNAPSHOT version though?
> >
> > Let's say we create release branch 2.1.0-branch from master. We roll the
> > master version to 2.1.1-SNAPSHOT (for example) after the 2.1.0 branch is
> > created. We then get a bug fix that should go in 2.1.0. In this case we
> > should merge it to 2.1.0-branch, then merge 2.1.0-branch to master. In
> Jira
> > we mark it as going in 2.1.0.
> >
> > We then get a PR that shouldn't be included in 2.1.0. We just merge it to
> > master, and mark it as 2.1.1 in Jira.
> >
> > Finally once 2.1.0 is released, we merge 2.1.0-branch into master and
> > delete 2.1.0-branch.
> >
> > Why is there a need to 2.1-SNAPSHOT?
> >
> > Den man. 19. aug. 2019 kl. 18.15 skrev Ethan Li <
> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>:
> >
> >> Many issues came up while I was preparing for 2.1.0 release. Freezing
> >> merge until the release is done is not practical.  So I am proposing:
> >>
> >> 1. Once we decide to make a release, we create a new branch based on
> >> master and start release process.
> >> 2. During the new process, master is still open for backwards
> >> compatibility commits, including new features, bu g fixes, etc.
> >> 3. Only bug fixes will be merged to the new branch and we need to
> restart
> >> the release process to include the bug fixes.
> >> 4. To avoid too much confusion on pom versions when we merge new commits
> >> during the release process,  we should use less concrete version. For
> >> example, in 2.1.x-branch, the pom version should be 2.1-SNAPSHOT,
> instead
> >> of 2.1.0-SNAPSHOT.
> >>
> >> For example,
> >>
> >> Let’s say we have a new branch 2.1.x-branch, the pom version is
> >> 2.1.0-SNAPSHOT. We start the release process and after running the mvn
> >> release:prepare -Pxxx command, the pom version changes to
> 2.1.1-SNAPSHOT,
> >> and before that a git tag v2.1.0 is created.  Now if there is a bug fix
> we
> >> have to merge in, so we merge in and it’s actually merged in to
> >> 2.1.1-SNAPSHOT at this point if we don’t manually revert the pom
> version,
> >> which can be confusing.  We can avoid this problem by just using
> >> 2.1-SNAPSHOT as the pom version. So it doesn’t have to change.
> >>
> >> Please let me know if there is any potential risk for doing this.
> >>
> >> Thanks
> >> Ethan
> >>
> >>> On Aug 19, 2019, at 10:25 AM, Ethan Li <ethanopensource@gmail.com>
> >> wrote:
> >>>
> >>> The pull request for the fix is
> >> https://github.com/apache/storm/pull/3106 <
> >> https://github.com/apache/storm/pull/3106 <
> https://github.com/apache/storm/pull/3106>>
> >>>
> >>>> On Aug 19, 2019, at 10:15 AM, Ethan Li <ethanopensource@gmail.com
> <mailto:ethanopensource@gmail.com>
> >> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>>
> wrote:
> >>>>
> >>>> So I was preparing for a new release candidate i.e. rc3. I can build
> it
> >> from source without any problem. Then I set up a standalone cluster and
> >> submitted a WordCountTopology. The workers kept restarting because of
> >>>>
> >>>>
> >>>> 2019-08-19 15:09:49.635 o.a.s.t.ShellBolt Thread-30 [ERROR] Halting
> >> process: ShellBolt died. Command: [python, splitsentence.py],
> ProcessInfo
> >> pid:3756, name:split exitCode:-1, errorString:
> >>>> java.lang.IllegalArgumentException: command sync is not supported
> >>>>        at
> >>
> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
> >> [storm-client-2.1.0.jar:2.1.0]
> >>>>        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
> >>>> 2019-08-19 15:09:49.635 o.a.s.e.e.ReportError Thread-30 [ERROR] Error
> >>>> java.lang.IllegalArgumentException: command sync is not supported
> >>>>        at
> >>
> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
> >> [storm-client-2.1.0.jar:2.1.0]
> >>>>        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
> >>>> 2019-08-19 15:09:49.636 o.a.s.t.ShellBolt Thread-28 [ERROR] Halting
> >> process: ShellBolt died. Command: [python, splitsentence.py],
> ProcessInfo
> >> pid:3755, name:split exitCode:-1, errorString:
> >>>> java.lang.IllegalArgumentException: command sync is not supported
> >>>>        at
> >>
> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
> >> [storm-client-2.1.0.jar:2.1.0]
> >>>>        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
> >>>> 2019-08-19 15:09:49.637 o.a.s.e.e.ReportError Thread-28 [ERROR] Error
> >>>> java.lang.IllegalArgumentException: command sync is not supported
> >>>>        at
> >>
> org.apache.storm.task.ShellBolt$BoltReaderRunnable.run(ShellBolt.java:366)
> >> [storm-client-2.1.0.jar:2.1.0]
> >>>>        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_181]
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> <
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> >
> >> <
> >>
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> <
> https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/task/ShellBolt.java#L365-L367
> >>
> >> I believe we shouldn’t throw exceptions here.
> >>>>
> >>>> Will make a pull request to fix it.
> >>>>
> >>>>
> >>>>
> >>>>> On Aug 14, 2019, at 11:11 PM, Ethan Li <ethanopensource@gmail.com
> <mailto:ethanopensource@gmail.com>
> >> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>>
> wrote:
> >>>>>
> >>>>> Hi Taylor,
> >>>>>
> >>>>> Mostly I was able to follow the doc
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> >
> >> <
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote
> >>,
> >> except:
> >>>>>
> >>>>> For Step 1,  I used the following command as suggested.
> >>>>> mvn release:prepare -P dist,rat,externals,examples
> >>>>> mvn release:perform -P dist,rat,externals,examples
> >>>>>
> >>>>>
> >>>>> For Step3,  I had to run "git checkout tags/v2.1.0 -b v2.1.0” so that
> >> I can run “mvn package” for storm-dist/binary and storm-dist/source
> based
> >> on v2.1.0. Otherwise if I run “mvn package” on 2.1.x-branch, it will
> fail
> >> because the pom version is “2.1.x-SNAPSHOT”.
> >>>>>
> >>>>> Then I find packages in storm-dist/binary/final-package/target and
> >> storm-dist/source/target, sign them, generate checksum and copy them to
> svn.
> >>>>>
> >>>>> I think there are something I should do. But please let me know if I
> >> was doing something wrong.  I will  also update the doc after the
> release
> >> is complete. Thank you very much!
> >>>>>
> >>>>> Ethan
> >>>>>
> >>>>>
> >>>>>> On Aug 14, 2019, at 12:24 PM, Ethan Li <ethanopensource@gmail.com
> <mailto:ethanopensource@gmail.com>
> >> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>>
> wrote:
> >>>>>>
> >>>>>> I am continuing for another release candidate since the pr is
> merged.
> >>>>>>
> >>>>>>> On Aug 13, 2019, at 11:58 AM, Stig Rohde Døssing <
> >> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com> <mailto:
> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>>> wrote:
> >>>>>>>
> >>>>>>> Updated https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053> <
> >> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053>> so we don't have
> >>>>>>> org.apache.storm artifacts in the DEPENDENCY-LICENSES file. It's
> >> ready for
> >>>>>>> review if someone wants to look at it.
> >>>>>>>
> >>>>>>> Den tir. 13. aug. 2019 kl. 18.21 skrev Ethan Li <
> >> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:
> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>>:
> >>>>>>>
> >>>>>>>> Thank you, Taylor. Will delete them.
> >>>>>>>>
> >>>>>>>>> On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <ptgoetz@gmail.com
> <mailto:ptgoetz@gmail.com>
> >> <mailto:ptgoetz@gmail.com <mailto:ptgoetz@gmail.com>>> wrote:
> >>>>>>>>>
> >>>>>>>>> Those can be safely deleted.
> >>>>>>>>>
> >>>>>>>>> -Taylor
> >>>>>>>>>
> >>>>>>>>>> On Aug 13, 2019, at 12:15 PM, Ethan Li <
> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>
> >> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Do we need/want to clean up the release candidate from
> >>>>>>>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm> <
> >> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm>> <
> >>>>>>>> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm> <
> >> https://dist.apache.org/repos/dist/dev/storm <
> https://dist.apache.org/repos/dist/dev/storm>>> ?
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >> <
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>>
> >>>>>>>> <
> >>>>>>>>
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >> <
> >>
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> <
> https://github.com/apache/storm/blob/master/RELEASING.md#cleaning-up-if-the-vote-fails
> >
> >>>>
> >>>>>>>> says we do. But we have a lot of rc in
> >>>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/> <
> >> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/>> <
> >>>>>>>> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/> <
> >> https://dist.apache.org/repos/dist/dev/storm/ <
> https://dist.apache.org/repos/dist/dev/storm/>>>
> >>>>>>>>>>
> >>>>>>>>>> Just want to be absolutely sure about this. Thanks.
> >>>>>>>>>>
> >>>>>>>>>>> On Aug 13, 2019, at 10:56 AM, Ethan Li <
> >> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:
> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>>
> >>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> That sounds better. It will be easier for release. Thank you
> for
> >>>>>>>> looking into this.
> >>>>>>>>>>>
> >>>>>>>>>>>> On Aug 13, 2019, at 10:54 AM, Stig Rohde Døssing <
> >>>>>>>> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com> <mailto:
> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Makes sense. I'll take a look at it. Ideally I'd want the
> >> license
> >>>>>>>> files to
> >>>>>>>>>>>> just not include org.apache.storm artifacts. I don't think we
> >> need to
> >>>>>>>> tell
> >>>>>>>>>>>> people that the project depends on itself.
> >>>>>>>>>>>>
> >>>>>>>>>>>> If we can exclude these artifacts from the lists, I don't
> think
> >> the
> >>>>>>>> release
> >>>>>>>>>>>> plugin needs to update these files.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Den tir. 13. aug. 2019 kl. 17.36 skrev Ethan Li <
> >>>>>>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>
> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>>:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Thanks Stig.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> In this case, we probably should abort release process and
> get
> >> this
> >>>>>>>> merged
> >>>>>>>>>>>>> into master first. Also we need to make sure it works with
> “mvn
> >>>>>>>>>>>>> release:prepare” since “ mvn release:prepare” will
> >> automatically
> >>>>>>>> push two
> >>>>>>>>>>>>> commits. For example,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> (1) [maven-release-plugin] prepare release v2.1.0:  this
> commit
> >>>>>>>> changes
> >>>>>>>>>>>>> the pom version to 2.1.0, push the commit, and then create a
> >> git tag
> >>>>>>>> v2.1.0.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> (2)  [maven-release-plugin] prepare for next development
> >> iteration:
> >>>>>>>> this
> >>>>>>>>>>>>> commit changes the pom version to 2.1.1-SNAPSHOT.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> We need DEPENDENCY-LICENSES to be updated on every step.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Aug 13, 2019, at 10:24 AM, Stig Rohde Døssing <
> >>>>>>>> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com> <mailto:
> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Oops, sorry that's not right. The license plugin setup was
> >> disabled
> >>>>>>>> in
> >>>>>>>>>>>>>> https://github.com/apache/storm/pull/3031 <
> https://github.com/apache/storm/pull/3031> <
> >> https://github.com/apache/storm/pull/3031 <
> https://github.com/apache/storm/pull/3031>> due to a bug in the
> >>>>>>>> license
> >>>>>>>>>>>>>> plugin. It is added back in
> >>>>>>>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053> <
> >> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053>>,
> >>>>>>>>>>>>>> where we've upgraded the plugin. Until that PR goes in, we
> >> can't
> >>>>>>>> easily
> >>>>>>>>>>>>>> regenerate DEPENDENCY-LICENSES.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Den tir. 13. aug. 2019 kl. 17.15 skrev Stig Rohde Døssing <
> >>>>>>>>>>>>>> stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>
> <mailto:stigdoessing@gmail.com <mailto:stigdoessing@gmail.com>>>:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> There's a script that can help you do it in
> >>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053> <
> >> https://github.com/apache/storm/pull/3053 <
> https://github.com/apache/storm/pull/3053>>. It checks the
> >>>>>>>>>>>>>>> DEPENDENCY-LICENSES and LICENSE-binary contain the right
> >>>>>>>> dependencies,
> >>>>>>>>>>>>> and
> >>>>>>>>>>>>>>> prints which licenses are redundant or should be added.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> For DEPENDENCY-LICENSES specifically you can run "mvn
> >>>>>>>>>>>>>>>
> license:aggregate-add-third-party@generate-and-check-licenses
> >>>>>>>>>>>>>>> -Dlicense.skipAggregateAddThirdParty=false -B" in the
> project
> >>>>>>>> root. It
> >>>>>>>>>>>>>>> should update the file for you.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Den tir. 13. aug. 2019 kl. 17.06 skrev Ethan Li <
> >>>>>>>>>>>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>
> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>
> >>>>>>>>>>>>>>>> :
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Hi Stig,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> How do we update
> >>>>>>>>>>>>>>>>
> >> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
> >> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>>
> >>>>>>>> <
> >>>>>>>>>>>>>>>>
> >> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?> <
> >> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES? <
> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>>>
> >>>>>>>> Is
> >>>>>>>>>>>>>>>> there a command I can use? Or I just replace strings
> >> manually?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Thanks
> >>>>>>>>>>>>>>>> Ethan
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Aug 12, 2019, at 3:54 PM, Ethan Li <
> >> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com> <mailto:
> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>
> >>>>>>>>>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Yes my public keys in that file. Thanks! Ready to set up
> a
> >> vote.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Aug 12, 2019, at 3:52 PM, P. Taylor Goetz <
> >> ptgoetz@gmail.com <mailto:ptgoetz@gmail.com> <mailto:ptgoetz@gmail.com
> <mailto:ptgoetz@gmail.com>>
> >>>>>>>>>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Yes. Is you public key in that file? If not you should
> >> add it.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> -Taylor
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Aug 12, 2019, at 4:15 PM, Ethan Li <
> >>>>>>>> ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>
> <mailto:ethanopensource@gmail.com <mailto:ethanopensource@gmail.com>>>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I have one more question before I can start a vote.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> In previous [VOTE] thread, Taylor always has this:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> The release artifacts are signed with the following
> key:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>
> >>
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
> <
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
> >
> >> <
> >>
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
> <
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
> >
> >>>
> >>>>>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>
> >>
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
> >> <
> >>
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
> >>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Does anyone know where to find the updated KEYs file?
> >> Should I
> >>>>>>>> just
> >>>>>>>>>>>>>>>> use https://www.apache.org/dist/storm/KEYS <
> >>>>>>>>>>>>>>>> https://www.apache.org/dist/storm/KEYS> ?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> Thanks very much
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On Aug 12, 2019, at 9:44 AM, Ethan Li <
> >>>>>>>> ethanopensource@gmail.com>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Thanks Stig and Taylor! It worked. I will continue the
> >>>>>>>> process now
> >>>>>>>>>>>>>>>> and update the documentation later.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Aug 12, 2019, at 9:40 AM, P. Taylor Goetz <
> >>>>>>>> ptgoetz@gmail.com>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> For the 2.x version lines, there are a bunch of
> >> profiles you
> >>>>>>>> need
> >>>>>>>>>>>>>>>> to enable. This is what I use when preparing a release:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> -P dist,include-shaded-deps,rat,externals,examples
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> -Taylor
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> On Aug 12, 2019, at 9:27 AM, Stig Rohde Døssing <
> >>>>>>>>>>>>>>>> stigdoessing@gmail.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Try enabling the "dist" profile by adding "-P
> >>>>>>>>>>>>>>>> dist,externals,examples" to
> >>>>>>>>>>>>>>>>>>>>>> the command you're running. See
> >>>>>>>>>>>>>>>>>>>>>>
> >> https://github.com/apache/storm/blob/master/pom.xml#L518.
> >>>>>>>> Unless
> >>>>>>>>>>>>>>>> you enable
> >>>>>>>>>>>>>>>>>>>>>> that profile, the storm-dist modules aren't in the
> >> reactor.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Den man. 12. aug. 2019 kl. 15.15 skrev Ethan Li <
> >>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Just in case if anyone happens to know the answer:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I created a branch
> >>>>>>>>>>>>>>>> https://github.com/apache/storm/tree/2.1.x-branch <
> >>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/tree/2.1.x-branch>
> >> and ran
> >>>>>>>>>>>>>>>> “mvn:prepare”
> >>>>>>>>>>>>>>>>>>>>>>> and “mvn:perform”. It created two commits and
> >> created a
> >>>>>>>> v2.1.0
> >>>>>>>>>>>>>>>> git tag. But
> >>>>>>>>>>>>>>>>>>>>>>> I realized that the pom version under storm-dist
> was
> >> not
> >>>>>>>> updated
> >>>>>>>>>>>>>>>> and it’s
> >>>>>>>>>>>>>>>>>>>>>>> still 2.0.1-SNAPSHOT. I checked the commits in
> other
> >> tags
> >>>>>>>> like
> >>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/commits/v2.0.0 <
> >>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/commits/v2.0.0>
> and
> >> it
> >>>>>>>> looks
> >>>>>>>>>>>>> like
> >>>>>>>>>>>>>>>>>>>>>>> storm-dist got updated within the “mvn:prepare”
> >> step.  How
> >>>>>>>> do I
> >>>>>>>>>>>>>>>> get
> >>>>>>>>>>>>>>>>>>>>>>> storm-dist pom version updated with “mv:prepare”?
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I am currently blocked on this. Any help will be
> >>>>>>>> appreciated.
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>>>>> Ethan
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> On Aug 12, 2019, at 2:38 AM, Stig Rohde Døssing <
> >>>>>>>>>>>>>>>> stigdoessing@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Sounds good Ethan.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Derek, I also think being clear about how long we
> >> expect
> >>>>>>>> to
> >>>>>>>>>>>>>>>> support a
> >>>>>>>>>>>>>>>>>>>>>>>> release line is a good idea. Maybe we should do a
> >> separate
> >>>>>>>>>>>>>>>> discuss thread
> >>>>>>>>>>>>>>>>>>>>>>>> on this, or if you already have a good idea for
> >> what the
> >>>>>>>> policy
> >>>>>>>>>>>>>>>> should
> >>>>>>>>>>>>>>>>>>>>>>> look
> >>>>>>>>>>>>>>>>>>>>>>>> like you could put it up as a PR for either the
> >> Downloads
> >>>>>>>> page
> >>>>>>>>>>>>>>>> or a new
> >>>>>>>>>>>>>>>>>>>>>>>> page on the Storm site?
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> Den søn. 11. aug. 2019 kl. 08.37 skrev Ethan Li <
> >>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> I am doing the release following
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> https://github.com/apache/storm/blob/master/RELEASING.md
> >>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >> https://github.com/apache/storm/blob/master/RELEASING.md>
> >>>>>>>> . I
> >>>>>>>>>>>>>>>> made some
> >>>>>>>>>>>>>>>>>>>>>>>>> progress but I have some questions so I just sent
> >> an
> >>>>>>>> email to
> >>>>>>>>>>>>>>>> Taylor.
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Please don’t merge anything to master or
> >> 2.1.x-branch
> >>>>>>>> for now.
> >>>>>>>>>>>>>>>> Thanks
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Best,
> >>>>>>>>>>>>>>>>>>>>>>>>> Ethan
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 9, 2019, at 4:45 PM, Ethan Li <
> >>>>>>>>>>>>>>>> ethanopensource@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Currently we have two outstanding PRs that we
> >> wanted to
> >>>>>>>>>>>>>>>> include in the
> >>>>>>>>>>>>>>>>>>>>>>>>> new release:
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3096 <
> >>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3096>
> >> (Travis has
> >>>>>>>> some
> >>>>>>>>>>>>>>>> issues
> >>>>>>>>>>>>>>>>>>>>>>>>> connecting to repository.apache.org <
> >>>>>>>>>>>>>>>> http://repository.apache.org/>
> >>>>>>>>>>>>>>>>>>>>>>>>> recently. Travis build fails consistently)
> >>>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878 <
> >>>>>>>>>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878> (Some
> >>>>>>>> comments are
> >>>>>>>>>>>>>>>> to be
> >>>>>>>>>>>>>>>>>>>>>>>>> addressed but Author hasn’t responded yet.)
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> It’s not absolutely necessary to include them in
> >> this
> >>>>>>>> new
> >>>>>>>>>>>>>>>> release so I
> >>>>>>>>>>>>>>>>>>>>>>>>> think I should move forward with the release
> >> process.
> >>>>>>>> These
> >>>>>>>>>>>>> two
> >>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>> other
> >>>>>>>>>>>>>>>>>>>>>>>>> PRs can be included in the next release.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> For the release, I will create a new branch
> >> 2.1.x-branch
> >>>>>>>>>>>>> based
> >>>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>>>>>>> current master branch, and release 2.1.0 from
> >> there.   I
> >>>>>>>> will
> >>>>>>>>>>>>>>>> then move
> >>>>>>>>>>>>>>>>>>>>>>>>> master to 2.2.0-SNAPSHOT.  Please let me know if
> >> there
> >>>>>>>> is any
> >>>>>>>>>>>>>>>>>>>>>>> objections.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>>>>>>>> Ethan
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 9, 2019, at 2:53 PM, Derek Dagit <
> >>>>>>>> dagit@apache.org
> >>>>>>>>>>>>>>>> <mailto:
> >>>>>>>>>>>>>>>>>>>>>>>>> dagit@apache.org>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> We might not able to say how long we want to
> >> support a
> >>>>>>>>>>>>>>>> specific
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> release line but I would love to see a clear
> >> release
> >>>>>>>> policy
> >>>>>>>>>>>>>>>> being
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> made.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> That makes sense. It seems better for us not to
> >> choose
> >>>>>>>> a
> >>>>>>>>>>>>>>>> specific
> >>>>>>>>>>>>>>>>>>>>>>>>>>> calendar date or duration of time.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> - We do not want too many release lines
> supported
> >>>>>>>>>>>>>>>> concurrently.
> >>>>>>>>>>>>>>>>>>>>>>>>>>> - We want devs and users to know what to
> expect.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Derek
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 09, 2019 at 10:32:59AM -0500, Ethan
> >> Li
> >>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Derek,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> I think it’s a good idea to be more clear on
> the
> >>>>>>>> versioning
> >>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>> release process so users and developers know what
> >> to
> >>>>>>>> expect.
> >>>>>>>>>>>>> We
> >>>>>>>>>>>>>>>> might
> >>>>>>>>>>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>>>>>>>>>> able to say how long we want to support a
> specific
> >>>>>>>> release
> >>>>>>>>>>>>> line
> >>>>>>>>>>>>>>>> but I
> >>>>>>>>>>>>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>>>>>>>>>>> love to see a clear release policy being made.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>> Ethan
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 9, 2019, at 8:53 AM, Derek Dagit <
> >>>>>>>> dagit@apache.org
> >>>>>>>>>>>>>>>> <mailto:
> >>>>>>>>>>>>>>>>>>>>>>>>> dagit@apache.org>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Aug 09, 2019 at 02:35:57PM +0200,
> Stig
> >> Rohde
> >>>>>>>>>>>>>>>> Døssing wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Where on the Traffic Server page do they
> list
> >> how
> >>>>>>>> long
> >>>>>>>>>>>>>>>> their
> >>>>>>>>>>>>>>>>>>>>>>> release
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> trains survive? I only see dates of release,
> >> not
> >>>>>>>> how long
> >>>>>>>>>>>>>>>> e.g. 7.x
> >>>>>>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> supposed to receive support.  Derek,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is a better link:
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >> https://cwiki.apache.org/confluence/display/TS/Release+Management
> >>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >> https://cwiki.apache.org/confluence/display/TS/Release+Management
> >>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> This example, where "RM" means "Release
> >> Manager":
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1. We promise to make 1 major release /
> year,
> >> but
> >>>>>>>> the RM
> >>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>> community
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> can of course make more as necessary
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2. We only make releases off the LTS
> branches,
> >>>>>>>> which are
> >>>>>>>>>>>>>>>> cut once a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> year off master
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 3. Master is always open, for any type of
> >> change
> >>>>>>>>>>>>> (including
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> incompatible changes). But don't break
> >>>>>>>> compatibility just
> >>>>>>>>>>>>>>>> for fun!
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 4. Master is always stable, i.e. commits
> >> should be
> >>>>>>>>>>>>>>>> properly tested
> >>>>>>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> reviewed before committed to master.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 5. All releases are stable releases,
> following
> >>>>>>>> strict
> >>>>>>>>>>>>>>>> Semantic
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Versioning.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 6. Minor releases are made at the discretion
> >> at the
> >>>>>>>>>>>>>>>> discretion of
> >>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> community and the RM.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 7. Minor releases can include new (small /
> >> safe)
> >>>>>>>>>>>>> features,
> >>>>>>>>>>>>>>>> but must
> >>>>>>>>>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> compatible within the LTS major version.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 8. The LTS cycle, 2 years + 6 months Sunset,
> >> does
> >>>>>>>> not
> >>>>>>>>>>>>>>>> reset when we
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> make a minor release.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Now, I am not proposing we do exactly this.
> >> The goal
> >>>>>>>> would
> >>>>>>>>>>>>>>>> be to set
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> expectations among developers and the
> >> community, and
> >>>>>>>> here
> >>>>>>>>>>>>>>>> is one
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> concrete example of how it could be done.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> If we're going to promise that a release
> line
> >>>>>>>> survives
> >>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>> a given
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> amount of time, I think we should do it at
> >> the major
> >>>>>>>>>>>>>>>> version level
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> only
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yeah, that sounds reasonable to me. If we
> >> choose to
> >>>>>>>> commit
> >>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>> something
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> like the above, we should base the decision
> in
> >> part
> >>>>>>>> on
> >>>>>>>>>>>>> what
> >>>>>>>>>>>>>>>> kind of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>> resources we have so that we do not
> >> over-commit.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 9. aug. 2019 kl. 00.15 skrev Derek
> >> Dagit <
> >>>>>>>>>>>>>>>>>>>>>>> dagit@apache.org
> >>>>>>>>>>>>>>>>>>>>>>>>> <mailto:dagit@apache.org>>:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> What do we think about defining Long-Term
> >> Support
> >>>>>>>>>>>>>>>> branches with a
> >>>>>>>>>>>>>>>>>>>>>>>>> fixed
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> period of support?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For example, we could say 2.0.x is an LTS
> >> release
> >>>>>>>> line
> >>>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>>>>> support
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ending no earlier than a certain calendar
> >> date.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The date could be extended, and it might
> >>>>>>>> ultimately be
> >>>>>>>>>>>>>>>> governed by
> >>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> timing of the subsequent release (e.g.,
> >> 2.1.x or
> >>>>>>>> 3.0.x).
> >>>>>>>>>>>>>>>> Keeping
> >>>>>>>>>>>>>>>>>>>>>>>>> things
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> clear would imply semantic versioning as
> >> mentioned
> >>>>>>>>>>>>> earlier
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (https://semver.org/ <https://semver.org/
> >).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Apache Traffic Server does something like
> >> this, to
> >>>>>>>> name
> >>>>>>>>>>>>>>>> one
> >>>>>>>>>>>>>>>>>>>>>>> project:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://trafficserver.apache.org/downloads
> <
> >>>>>>>>>>>>>>>>>>>>>>>>> https://trafficserver.apache.org/downloads>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Having a regular cadence of releases might
> >> also
> >>>>>>>> help
> >>>>>>>>>>>>> make
> >>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>> process
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> easier and help set expectations for users
> >> and
> >>>>>>>> devs.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Derek
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Aug 08, 2019 at 02:50:07PM -0500,
> >> Ethan Li
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Currently we don’t have a 2.0.x-branch and
> >> master
> >>>>>>>> is
> >>>>>>>>>>>>>>>> actually
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> “2.0.1-SNAPSHOT”.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So if we  do a 2.1.0 release,  we will
> >> create a
> >>>>>>>>>>>>>>>> 2.1.x-branch
> >>>>>>>>>>>>>>>>>>>>>>> based
> >>>>>>>>>>>>>>>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> current master, release from there. And we
> >> change
> >>>>>>>> master
> >>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> “2.2.0-SNAPSHOT”.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> But we will have one problem: we will lose
> >> 2.0.x
> >>>>>>>>>>>>> release
> >>>>>>>>>>>>>>>> line.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are two things I can do:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1) create a 2.0.x-branch based on v2.0.0
> >> tag.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2) ignore it. If there is an issue with
> >> 2.0.x
> >>>>>>>> release,
> >>>>>>>>>>>>>>>> ask users
> >>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> upgrade to 2.1.0.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I prefer 1) but not sure if it’s the right
> >> way to
> >>>>>>>> make
> >>>>>>>>>>>>>>>> things
> >>>>>>>>>>>>>>>>>>>>>>>>> right. Or
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> please let me know if I misunderstood
> >> something
> >>>>>>>> and it’s
> >>>>>>>>>>>>>>>> not an
> >>>>>>>>>>>>>>>>>>>>>>>>> issue.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Btw, I am seeing the same issue with
> >> 1.x-branch.
> >>>>>>>> We
> >>>>>>>>>>>>>>>> shouldn’t
> >>>>>>>>>>>>>>>>>>>>>>> have
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1.x-branch. Instead, we should have
> >> 1.2.x-branch.
> >>>>>>>> But
> >>>>>>>>>>>>>>>> this is not
> >>>>>>>>>>>>>>>>>>>>>>> a
> >>>>>>>>>>>>>>>>>>>>>>>>> problem
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> since we will not release 1.3.x.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ethan
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:43 AM, Ethan Li <
> >>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Yes thanks.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde
> >> Døssing
> >>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great. Remember to add your key
> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>> https://dist.apache.org/repos/dist/release/storm/KEYS,
> >>>>>>>>>>>>>>>> you
> >>>>>>>>>>>>>>>>>>>>>>>>> should be
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> able
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to update it with an SVN client. See
> also
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> https://www.apache.org/dev/openpgp.html#update.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den ons. 7. aug. 2019 kl. 15.05 skrev
> >> Ethan Li <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I got my pgp key signed by Bryan W.
> Call
> >> <
> >>>>>>>>>>>>>>>> bcall@apache.org
> >>>>>>>>>>>>>>>>>>>>>>>>> <mailto:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bcall@apache.org>> (Thanks to him).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My pgp key:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>
> >>
> http://pgp.surfnet.nl/pks/lookup?op=vindex&fingerprint=on&search=0xA4A672F11B5050C8
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>
> >>
> http://pgp.surfnet.nl/pks/lookup?op=vindex&fingerprint=on&search=0xA4A672F11B5050C8
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> My understanding is that I am good to
> do
> >>>>>>>> release
> >>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>> this key
> >>>>>>>>>>>>>>>>>>>>>>>>> now.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Here is a list of PRs that we might
> want
> >> to
> >>>>>>>> include
> >>>>>>>>>>>>>>>> in the new
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> https://github.com/apache/storm/pull/3098 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> https://github.com/apache/storm/pull/3098>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> https://github.com/apache/storm/pull/3096 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> https://github.com/apache/storm/pull/3096>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> https://github.com/apache/storm/pull/2878 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> https://github.com/apache/storm/pull/2878>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Please review if you get a chance.
> >> Thanks
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ethan
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Aug 1, 2019, at 4:19 AM, Stig Rohde
> >>>>>>>> Døssing <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev
> >> Ethan
> >>>>>>>> Li <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It’s a good point. I will start a
> >> discussion
> >>>>>>>>>>>>> thread
> >>>>>>>>>>>>>>>> for it.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> For the new release, I went through
> >> the list:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>
> >>
> https://issues.apache.org/jira/issues/?jql=project%20=%20STORM%20AND%20fixVersion%20=%202.0.1
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We introduced some new
> functionalities,
> >>>>>>>> including
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>> https://issues.apache.org/jira/browse/STORM-2720
> >>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>> https://issues.apache.org/jira/browse/STORM-2720>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>> https://issues.apache.org/jira/browse/STORM-3412
> >>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>> https://issues.apache.org/jira/browse/STORM-3412>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>> https://issues.apache.org/jira/browse/STORM-3411
> >>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>> https://issues.apache.org/jira/browse/STORM-3411>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>> https://issues.apache.org/jira/browse/STORM-3442
> >>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>> https://issues.apache.org/jira/browse/STORM-3442>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>> https://issues.apache.org/jira/browse/STORM-3396
> >>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>> https://issues.apache.org/jira/browse/STORM-3396>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>> https://issues.apache.org/jira/browse/STORM-3392
> >>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>> https://issues.apache.org/jira/browse/STORM-3392>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>> https://issues.apache.org/jira/browse/STORM-3395
> >>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>> https://issues.apache.org/jira/browse/STORM-3395>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> So I think we should release 2.1.0
> >> rather
> >>>>>>>> than
> >>>>>>>>>>>>>>>> 2.0.1.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> There are a few pull requests we may
> >> want to
> >>>>>>>>>>>>> review
> >>>>>>>>>>>>>>>> before
> >>>>>>>>>>>>>>>>>>>>>>>>> the next
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> https://github.com/apache/storm/pull/3094 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> https://github.com/apache/storm/pull/3094>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> https://github.com/apache/storm/pull/2990 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> https://github.com/apache/storm/pull/2990>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> https://github.com/apache/storm/pull/2878 <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> https://github.com/apache/storm/pull/2878>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ethan
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 29, 2019, at 10:11 AM, Hugo
> >> Louro <
> >>>>>>>>>>>>>>>>>>>>>>> hmclouro@gmail.com
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think it would facilitate more
> >> frequent
> >>>>>>>>>>>>> releases
> >>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>> summarize
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> in a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> page
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the testing that all
> >>>>>>>> contributors/committers do
> >>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>>>>>>> anticipation
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> of the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release, plus any "new" testing that
> >> may
> >>>>>>>> become
> >>>>>>>>>>>>>>>> relevant
> >>>>>>>>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> newer
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> releases. Doing so would make it
> easy
> >> to
> >>>>>>>> create a
> >>>>>>>>>>>>>>>> check
> >>>>>>>>>>>>>>>>>>>>>>> form
> >>>>>>>>>>>>>>>>>>>>>>>>> or or
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> email
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> template that what we feel should be
> >> done to
> >>>>>>>>>>>>>>>> guarantee a
> >>>>>>>>>>>>>>>>>>>>>>>>> stable
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hugo
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Jul 29, 2019 at 7:15 AM
> Ethan
> >> Li <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thanks Stig. I will look into it.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig
> >> Rohde
> >>>>>>>>>>>>> Døssing <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think ideally we've been trying
> >> for
> >>>>>>>> semver,
> >>>>>>>>>>>>>>>> but it's
> >>>>>>>>>>>>>>>>>>>>>>> been
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pretty
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> loose,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> e.g. there were breaking changes
> in
> >> one
> >>>>>>>> of the
> >>>>>>>>>>>>>>>> 1.2.x
> >>>>>>>>>>>>>>>>>>>>>>>>> releases
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> storm-kafka-client. I don't know
> >> what
> >>>>>>>> rules
> >>>>>>>>>>>>> we've
> >>>>>>>>>>>>>>>>>>>>>>> actually
> >>>>>>>>>>>>>>>>>>>>>>>>> been
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> using,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> if
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> any.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Semver for binary compatibility
> >> would
> >>>>>>>> probably
> >>>>>>>>>>>>>>>> be a good
> >>>>>>>>>>>>>>>>>>>>>>>>> rule of
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> thumb.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 20.01
> >> skrev
> >>>>>>>> Ethan
> >>>>>>>>>>>>> Li <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Stig,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Do you know what’s the versioning
> >>>>>>>> standard we
> >>>>>>>>>>>>>>>> have been
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> following
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> determine a 2.0.1 release or
> 2.1.0
> >>>>>>>> release) ?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 12:26 PM,
> >> Stig Rohde
> >>>>>>>>>>>>>>>> Døssing <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sounds great, thanks Ethan.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16
> >> skrev
> >>>>>>>> Ethan
> >>>>>>>>>>>>>>>> Li <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ethanopensource@gmail.com>:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It’s good idea to do more
> >> frequent
> >>>>>>>> release.
> >>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>> can run
> >>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> next
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I will take a look at both PRs.
> >> Other
> >>>>>>>> than
> >>>>>>>>>>>>>>>> that, I
> >>>>>>>>>>>>>>>>>>>>>>>>> think we
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> should
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> also
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> get
> >>>>>>>>>>>>> https://github.com/apache/storm/pull/3093
> >>>>>>>>>>>>>>>> <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>> https://github.com/apache/storm/pull/3093>
> >>>>>>>>>>>>>>>> in the
> >>>>>>>>>>>>>>>>>>>>>>> new
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Jul 26, 2019, at 11:58 AM,
> >> Stig
> >>>>>>>> Rohde
> >>>>>>>>>>>>>>>> Døssing <
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> stigdoessing@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think we've talked about
> more
> >>>>>>>> frequent
> >>>>>>>>>>>>>>>> releases
> >>>>>>>>>>>>>>>>>>>>>>>>> before.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Releasing
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> new
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> versions every few months
> means
> >> people
> >>>>>>>>>>>>> don't
> >>>>>>>>>>>>>>>> have to
> >>>>>>>>>>>>>>>>>>>>>>>>> wait
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> long
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fixes
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> get out, and smaller releases
> >> are
> >>>>>>>> probably
> >>>>>>>>>>>>>>>> also
> >>>>>>>>>>>>>>>>>>>>>>> easier
> >>>>>>>>>>>>>>>>>>>>>>>>> for
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> users
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> get
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> grips with (the fix list for
> >> 2.0.0 is
> >>>>>>>>>>>>>>>> enormous).
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> With that in mind, I think we
> >> should
> >>>>>>>> start
> >>>>>>>>>>>>>>>> looking at
> >>>>>>>>>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> next
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2.x
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> (2.0.1 or 2.1.0?), since it's
> >> been a
> >>>>>>>> couple
> >>>>>>>>>>>>>>>> of months
> >>>>>>>>>>>>>>>>>>>>>>>>> since
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2.0.0
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> released.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The fix list would be
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>
> >>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> .
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Govind and Ethan have offered
> >> to run
> >>>>>>>> the
> >>>>>>>>>>>>> next
> >>>>>>>>>>>>>>>>>>>>>>> release,
> >>>>>>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> help
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> validate
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> our release process
> guidelines.
> >> Would
> >>>>>>>> one
> >>>>>>>>>>>>> of
> >>>>>>>>>>>>>>>> you have
> >>>>>>>>>>>>>>>>>>>>>>>>> time
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> work
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on a
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> release in the near future?
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It would be good to take a
> look
> >> at
> >>>>>>>>>>>>> currently
> >>>>>>>>>>>>>>>> open PRs
> >>>>>>>>>>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> decide
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> which
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> we
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> feel need to get merged before
> >> the
> >>>>>>>> next
> >>>>>>>>>>>>>>>> release.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I would like to see at least
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >> https://github.com/apache/storm/pull/2990
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> merged
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>> https://github.com/apache/storm/pull/2878
> >>>>>>>>>>>>>>>> seems like
> >>>>>>>>>>>>>>>>>>>>>>>>> it's
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> close
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mergeable too?
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message