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 Tue, 13 Aug 2019 16:58:04 GMT
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 <ethanopensource@gmail.com>:

> Thank you, Taylor. Will delete them.
>
> > On Aug 13, 2019, at 11:19 AM, P. Taylor Goetz <ptgoetz@gmail.com> wrote:
> >
> > Those can be safely deleted.
> >
> > -Taylor
> >
> >> On Aug 13, 2019, at 12:15 PM, Ethan Li <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://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 <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> wrote:
> >>>>
> >>>> Makes sense. I'll take a look at it. Ideally I'd want the license
> files to
> >>>> just not include org.apache.storm artifacts. I don't think we need to
> tell
> >>>> people that the project depends on itself.
> >>>>
> >>>> If we can exclude these artifacts from the lists, I don't think the
> release
> >>>> plugin needs to update these files.
> >>>>
> >>>> Den tir. 13. aug. 2019 kl. 17.36 skrev Ethan Li <
> ethanopensource@gmail.com>:
> >>>>
> >>>>> Thanks Stig.
> >>>>>
> >>>>> In this case, we probably should abort release process and get this
> merged
> >>>>> into master first. Also we need to make sure it works with “mvn
> >>>>> release:prepare” since “ mvn release:prepare” will automatically
> push two
> >>>>> commits. For example,
> >>>>>
> >>>>> (1) [maven-release-plugin] prepare release v2.1.0:  this commit
> changes
> >>>>> the pom version to 2.1.0, push the commit, and then create a git tag
> v2.1.0.
> >>>>>
> >>>>> (2)  [maven-release-plugin] prepare for next development iteration:
> this
> >>>>> commit changes the pom version to 2.1.1-SNAPSHOT.
> >>>>>
> >>>>>
> >>>>> We need DEPENDENCY-LICENSES to be updated on every step.
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On Aug 13, 2019, at 10:24 AM, Stig Rohde Døssing <
> stigdoessing@gmail.com>
> >>>>> wrote:
> >>>>>>
> >>>>>> Oops, sorry that's not right. The license plugin setup was disabled
> in
> >>>>>> https://github.com/apache/storm/pull/3031 due to a bug in the
> license
> >>>>>> plugin. It is added back in
> https://github.com/apache/storm/pull/3053,
> >>>>>> where we've upgraded the plugin. Until that PR goes in, we can't
> easily
> >>>>>> regenerate DEPENDENCY-LICENSES.
> >>>>>>
> >>>>>> Den tir. 13. aug. 2019 kl. 17.15 skrev Stig Rohde Døssing <
> >>>>>> stigdoessing@gmail.com>:
> >>>>>>
> >>>>>>> There's a script that can help you do it in
> >>>>>>> https://github.com/apache/storm/pull/3053. It checks the
> >>>>>>> DEPENDENCY-LICENSES and LICENSE-binary contain the right
> dependencies,
> >>>>> and
> >>>>>>> prints which licenses are redundant or should be added.
> >>>>>>>
> >>>>>>> For DEPENDENCY-LICENSES specifically you can run "mvn
> >>>>>>> license:aggregate-add-third-party@generate-and-check-licenses
> >>>>>>> -Dlicense.skipAggregateAddThirdParty=false -B" in the project
> root. It
> >>>>>>> should update the file for you.
> >>>>>>>
> >>>>>>> Den tir. 13. aug. 2019 kl. 17.06 skrev Ethan Li <
> >>>>> ethanopensource@gmail.com
> >>>>>>>> :
> >>>>>>>
> >>>>>>>> Hi Stig,
> >>>>>>>>
> >>>>>>>> How do we update
> >>>>>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?
> <
> >>>>>>>> https://github.com/apache/storm/blob/v2.1.0/DEPENDENCY-LICENSES?>
> Is
> >>>>>>>> there a command I can use? Or I just replace strings manually?
> >>>>>>>>
> >>>>>>>> Thanks
> >>>>>>>> Ethan
> >>>>>>>>
> >>>>>>>>> On Aug 12, 2019, at 3:54 PM, Ethan Li <ethanopensource@gmail.com
> >
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> Yes my public keys in that file. Thanks! Ready to set up a vote.
> >>>>>>>>>
> >>>>>>>>>> On Aug 12, 2019, at 3:52 PM, P. Taylor Goetz <ptgoetz@gmail.com
> >
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Yes. Is you public key in that file? If not you should add it.
> >>>>>>>>>>
> >>>>>>>>>> -Taylor
> >>>>>>>>>>
> >>>>>>>>>>> On Aug 12, 2019, at 4:15 PM, Ethan Li <
> ethanopensource@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> I have one more question before I can start a vote.
> >>>>>>>>>>>
> >>>>>>>>>>> In previous [VOTE] thread, Taylor always has this:
> >>>>>>>>>>>
> >>>>>>>>>>> The release artifacts are signed with the following key:
> >>>>>>>>>>>
> >>>>>>>>
> >>>>>
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
> >>>>>>>> <
> >>>>>>>>
> >>>>>
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
> >>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Does anyone know where to find the updated KEYs file? Should I
> just
> >>>>>>>> use https://www.apache.org/dist/storm/KEYS <
> >>>>>>>> https://www.apache.org/dist/storm/KEYS> ?
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks very much
> >>>>>>>>>>>
> >>>>>>>>>>>> On Aug 12, 2019, at 9:44 AM, Ethan Li <
> ethanopensource@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks Stig and Taylor! It worked. I will continue the
> process now
> >>>>>>>> and update the documentation later.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On Aug 12, 2019, at 9:40 AM, P. Taylor Goetz <
> ptgoetz@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> For the 2.x version lines, there are a bunch of profiles you
> need
> >>>>>>>> to enable. This is what I use when preparing a release:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -P dist,include-shaded-deps,rat,externals,examples
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -Taylor
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Aug 12, 2019, at 9:27 AM, Stig Rohde Døssing <
> >>>>>>>> stigdoessing@gmail.com> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Try enabling the "dist" profile by adding "-P
> >>>>>>>> dist,externals,examples" to
> >>>>>>>>>>>>>> the command you're running. See
> >>>>>>>>>>>>>> https://github.com/apache/storm/blob/master/pom.xml#L518.
> Unless
> >>>>>>>> you enable
> >>>>>>>>>>>>>> that profile, the storm-dist modules aren't in the reactor.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Den man. 12. aug. 2019 kl. 15.15 skrev Ethan Li <
> >>>>>>>> ethanopensource@gmail.com>:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Just in case if anyone happens to know the answer:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I created a branch
> >>>>>>>> https://github.com/apache/storm/tree/2.1.x-branch <
> >>>>>>>>>>>>>>> https://github.com/apache/storm/tree/2.1.x-branch> and ran
> >>>>>>>> “mvn:prepare”
> >>>>>>>>>>>>>>> and “mvn:perform”. It created two commits and created a
> v2.1.0
> >>>>>>>> git tag. But
> >>>>>>>>>>>>>>> I realized that the pom version under storm-dist was not
> updated
> >>>>>>>> and it’s
> >>>>>>>>>>>>>>> still 2.0.1-SNAPSHOT. I checked the commits in other tags
> like
> >>>>>>>>>>>>>>> https://github.com/apache/storm/commits/v2.0.0 <
> >>>>>>>>>>>>>>> https://github.com/apache/storm/commits/v2.0.0> and it
> looks
> >>>>> like
> >>>>>>>>>>>>>>> storm-dist got updated within the “mvn:prepare” step.  How
> do I
> >>>>>>>> get
> >>>>>>>>>>>>>>> storm-dist pom version updated with “mv:prepare”?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I am currently blocked on this. Any help will be
> appreciated.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>> Ethan
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Aug 12, 2019, at 2:38 AM, Stig Rohde Døssing <
> >>>>>>>> stigdoessing@gmail.com>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Sounds good Ethan.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Derek, I also think being clear about how long we expect
> to
> >>>>>>>> support a
> >>>>>>>>>>>>>>>> release line is a good idea. Maybe we should do a separate
> >>>>>>>> discuss thread
> >>>>>>>>>>>>>>>> on this, or if you already have a good idea for what the
> policy
> >>>>>>>> should
> >>>>>>>>>>>>>>> look
> >>>>>>>>>>>>>>>> like you could put it up as a PR for either the Downloads
> page
> >>>>>>>> or a new
> >>>>>>>>>>>>>>>> page on the Storm site?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Den søn. 11. aug. 2019 kl. 08.37 skrev Ethan Li <
> >>>>>>>>>>>>>>> ethanopensource@gmail.com>:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I am doing the release following
> >>>>>>>>>>>>>>>>> https://github.com/apache/storm/blob/master/RELEASING.md
> <
> >>>>>>>>>>>>>>>>> https://github.com/apache/storm/blob/master/RELEASING.md>
> . I
> >>>>>>>> made some
> >>>>>>>>>>>>>>>>> progress but I have some questions so I just sent an
> email to
> >>>>>>>> Taylor.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Please don’t merge anything to master or 2.1.x-branch
> for now.
> >>>>>>>> Thanks
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Best,
> >>>>>>>>>>>>>>>>> Ethan
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Aug 9, 2019, at 4:45 PM, Ethan Li <
> >>>>>>>> ethanopensource@gmail.com>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Currently we have two outstanding PRs that we wanted to
> >>>>>>>> include in the
> >>>>>>>>>>>>>>>>> new release:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3096 <
> >>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/3096> (Travis has
> some
> >>>>>>>> issues
> >>>>>>>>>>>>>>>>> connecting to repository.apache.org <
> >>>>>>>> http://repository.apache.org/>
> >>>>>>>>>>>>>>>>> recently. Travis build fails consistently)
> >>>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878 <
> >>>>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878> (Some
> comments are
> >>>>>>>> to be
> >>>>>>>>>>>>>>>>> addressed but Author hasn’t responded yet.)
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> It’s not absolutely necessary to include them in this
> new
> >>>>>>>> release so I
> >>>>>>>>>>>>>>>>> think I should move forward with the release process.
> These
> >>>>> two
> >>>>>>>> and
> >>>>>>>>>>>>>>> other
> >>>>>>>>>>>>>>>>> PRs can be included in the next release.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> For the release, I will create a new branch 2.1.x-branch
> >>>>> based
> >>>>>>>> on
> >>>>>>>>>>>>>>>>> current master branch, and release 2.1.0 from there.   I
> will
> >>>>>>>> then move
> >>>>>>>>>>>>>>>>> master to 2.2.0-SNAPSHOT.  Please let me know if there
> is any
> >>>>>>>>>>>>>>> objections.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>> Ethan
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Aug 9, 2019, at 2:53 PM, Derek Dagit <
> dagit@apache.org
> >>>>>>>> <mailto:
> >>>>>>>>>>>>>>>>> dagit@apache.org>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> We might not able to say how long we want to support a
> >>>>>>>> specific
> >>>>>>>>>>>>>>>>>>>> release line but I would love to see a clear release
> policy
> >>>>>>>> being
> >>>>>>>>>>>>>>>>>>>> made.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> That makes sense. It seems better for us not to choose
> a
> >>>>>>>> specific
> >>>>>>>>>>>>>>>>>>> calendar date or duration of time.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> - We do not want too many release lines supported
> >>>>>>>> concurrently.
> >>>>>>>>>>>>>>>>>>> - We want devs and users to know what to expect.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>> Derek
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Fri, Aug 09, 2019 at 10:32:59AM -0500, Ethan Li
> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Derek,
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I think it’s a good idea to be more clear on the
> versioning
> >>>>>>>> and
> >>>>>>>>>>>>>>>>> release process so users and developers know what to
> expect.
> >>>>> We
> >>>>>>>> might
> >>>>>>>>>>>>>>> not
> >>>>>>>>>>>>>>>>> able to say how long we want to support a specific
> release
> >>>>> line
> >>>>>>>> but I
> >>>>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>>> love to see a clear release policy being made.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Thanks,
> >>>>>>>>>>>>>>>>>>>> Ethan
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Aug 9, 2019, at 8:53 AM, Derek Dagit <
> dagit@apache.org
> >>>>>>>> <mailto:
> >>>>>>>>>>>>>>>>> dagit@apache.org>> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Fri, Aug 09, 2019 at 02:35:57PM +0200, Stig Rohde
> >>>>>>>> Døssing wrote:
> >>>>>>>>>>>>>>>>>>>>>> Where on the Traffic Server page do they list how
> long
> >>>>>>>> their
> >>>>>>>>>>>>>>> release
> >>>>>>>>>>>>>>>>>>>>>> trains survive? I only see dates of release, not
> how long
> >>>>>>>> e.g. 7.x
> >>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>>>> supposed to receive support.  Derek,
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> This is a better link:
> >>>>>>>>>>>>>>>>>
> >>>>>>>> https://cwiki.apache.org/confluence/display/TS/Release+Management
> <
> >>>>>>>>>>>>>>>>>
> >>>>>>>> https://cwiki.apache.org/confluence/display/TS/Release+Management
> >
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> This example, where "RM" means "Release Manager":
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> 1. We promise to make 1 major release / year, but
> the RM
> >>>>>>>> and
> >>>>>>>>>>>>>>>>> community
> >>>>>>>>>>>>>>>>>>>>>> can of course make more as necessary
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> 2. We only make releases off the LTS branches,
> which are
> >>>>>>>> cut once a
> >>>>>>>>>>>>>>>>>>>>>> year off master
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> 3. Master is always open, for any type of change
> >>>>> (including
> >>>>>>>>>>>>>>>>>>>>>> incompatible changes). But don't break
> compatibility just
> >>>>>>>> for fun!
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> 4. Master is always stable, i.e. commits should be
> >>>>>>>> properly tested
> >>>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>>>> reviewed before committed to master.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> 5. All releases are stable releases, following
> strict
> >>>>>>>> Semantic
> >>>>>>>>>>>>>>>>>>>>>> Versioning.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> 6. Minor releases are made at the discretion at the
> >>>>>>>> discretion of
> >>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>>>>> community and the RM.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> 7. Minor releases can include new (small / safe)
> >>>>> features,
> >>>>>>>> but must
> >>>>>>>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>>>>> compatible within the LTS major version.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> 8. The LTS cycle, 2 years + 6 months Sunset, does
> not
> >>>>>>>> reset when we
> >>>>>>>>>>>>>>>>>>>>>> make a minor release.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Now, I am not proposing we do exactly this. The goal
> would
> >>>>>>>> be to set
> >>>>>>>>>>>>>>>>>>>>> expectations among developers and the community, and
> here
> >>>>>>>> is one
> >>>>>>>>>>>>>>>>>>>>> concrete example of how it could be done.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> If we're going to promise that a release line
> survives
> >>>>> for
> >>>>>>>> a given
> >>>>>>>>>>>>>>>>>>>>>> amount of time, I think we should do it at the major
> >>>>>>>> version level
> >>>>>>>>>>>>>>>>>>>>>> only
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Yeah, that sounds reasonable to me. If we choose to
> commit
> >>>>>>>> to
> >>>>>>>>>>>>>>>>> something
> >>>>>>>>>>>>>>>>>>>>> like the above, we should base the decision in part
> on
> >>>>> what
> >>>>>>>> kind of
> >>>>>>>>>>>>>>>>>>>>> resources we have so that we do not over-commit.
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> Den fre. 9. aug. 2019 kl. 00.15 skrev Derek Dagit <
> >>>>>>>>>>>>>>> dagit@apache.org
> >>>>>>>>>>>>>>>>> <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