storm-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "P. Taylor Goetz" <ptgo...@gmail.com>
Subject Re: [DISCUSS] Next 2.x release
Date Mon, 12 Aug 2019 20:52:52 GMT
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