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 Mon, 12 Aug 2019 20:15:35 GMT
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