storm-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Li <ethanopensou...@gmail.com>
Subject Re: [DISCUSS] Next 2.x release
Date Tue, 13 Aug 2019 15:06:07 GMT
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