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:54:37 GMT
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
View raw message