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 14:40:35 GMT
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