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 15:54:25 GMT
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