You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@storm.apache.org by "P. Taylor Goetz" <pt...@gmail.com> on 2015/11/10 22:32:11 UTC
[DISCUSS] Plan for Merging JStorm Code
Based on a number of discussions regarding merging the JStorm code, I’ve tried to distill the ideas presented and inserted some of my own. The result is below.
I’ve divided the plan into three phases, though they are not necessarily sequential — obviously some tasks can take place in parallel.
None of this is set in stone, just presented for discussion. Any and all comments are welcome.
-------
Phase 1 - Plan for 0.11.x Release
1. Determine feature set for 0.11.x and publish to wiki [1].
2. Announce feature-freeze for 0.11.x
3. Create 0.11.x branch from master (Phase 2.4 can begin.)
4. Release 0.11.0 (or whatever version # we want to use)
5. Bug fixes and subsequent releases from 0.11.x-branch
Phase 2 - Prepare for Merge ("master" and "jstorm-import" branches)
1. Determine/document unique features in JStorm (e.g. classpath isolation, cgroups, etc.) and create JIRA for migrating the feature.
2. Create JIRA for migrating each clojure component (or logical group of components) to Java. Assumes tests will be ported as well.
3. Discuss/establish style guide for Java coding conventions. Consider using Oracle’s or Google’s Java conventions as a base — they are both pretty solid.
4. align package names (e.g backtype.storm --> org.apache.storm / com.alibaba.jstorm --> org.apache.storm) (Phase 3 can begin)
Phase 3 - Migrate Clojure --> Java
1. Port code/tests to Java, leveraging existing JStorm code wherever possible (core functionality only, features distinct to JStorm migrated separately).
2. Port JStorm-specific features.
3. Begin releasing preview/beta versions.
4. Code cleanup (across the board) and refactoring using established coding conventions, and leveraging PMD/Checkstyle reports for reference. (Note: good oportunity for new contributors.)
5. Release 0.12.0 (or whatever version # we want to use) and lift feature freeze.
Notes:
We should consider bumping up to version 1.0 sometime soon and then switching to semantic versioning [3] from then on.
With the exception of package name alignment, the "jstorm-import" branch will largely be read-only throughout the process.
During migration, it's probably easiest to operate with two local clones of the Apache Storm repo: one for working (i.e. checked out to working branch) and one for reference/copying (i.e. checked out to "jstorm-import").
Feature-freeze probably only needs to be enforced against core functionality. Components under "external" can likely be exempt, but we should figure out a process for accepting and releasing new features during the migration.
Performance testing should be continuous throughout the process. Since we don't really have ASF infrastructure for performance testing, we will need a volunteer(s) to host and run the performance tests. Performance test results can be posted to the wiki [2]. It would probably be a good idea to establish a baseline with the 0.10.0 release.
I’ve attached an analysis document Sean Zhong put together a while back to the JStorm merge JIRA [4]. The analysis was against the 0.9.3 release but is still relevant and has a lot of good information.
[1] https://cwiki.apache.org/confluence/display/STORM/Release+0.11.0+Feature+Set
[2] https://cwiki.apache.org/confluence/display/STORM/Storm+Home <https://cwiki.apache.org/confluence/display/STORM/Storm+Home>
[3] http://semver.org
[4] https://issues.apache.org/jira/browse/STORM-717
-Taylor
Re: [DISCUSS] Plan for Merging JStorm Code
Posted by "P. Taylor Goetz" <pt...@gmail.com>.
> On Nov 11, 2015, at 2:04 AM, Cody Innowhere <e....@gmail.com> wrote:
>
>> During migration, it's probably easiest to operate with two local clones
> of the Apache Storm repo: one for working (i.e. checked out to working
> branch) > and one for reference/copying (i.e. checked out to
> "jstorm-import").
> Do you mean two storm branches(both clojure core) or one storm branch with
> one JStorm-imported branch?
That paragraph was mainly me thinking out loud, and probably could have been left out.
I meant that as a developer working on merging two divergent branches branches, it might be easiest to have two local copies of the repo to do comparisons, diffs, etc., rather than working in one repo and having to constantly switch between branches.
That’s just the way I would likely do it. Ultimately it’s up to each individual developer’s personal preference.
-Taylor
答复：[DISCUSS] Plan for Merging JStorm Code
Posted by "瑾涵(王桐Wang Tong)" <wa...@alibaba-inc.com>.
sure, I can do the
performance test, do we have any
performance test cases ?------------------------------------------------------------------发件人：Cody Innowhere <e....@gmail.com>发送时间：2015年11月11日(星期三) 15:04收件人：dev <de...@storm.apache.org>主 题：Re: [DISCUSS] Plan for Merging JStorm Code
Thanks Taylor.
The plan looks good.
> During migration, it's probably easiest to operate with two local clones
of the Apache Storm repo: one for working (i.e. checked out to working
branch) > and one for reference/copying (i.e. checked out to
"jstorm-import").
Do you mean two storm branches(both clojure core) or one storm branch with
one JStorm-imported branch?
Tong.Wang is responsible for integration tests of JStorm, @Tong.Wang, could
you see to it if you can do the performace test?
On Wed, Nov 11, 2015 at 8:00 AM, Suresh Srinivas <su...@hortonworks.com>
wrote:
> +1 for 1.0.0 release.
>
> I also like Hackathon to encourage bigger participation. It will be fun.
>
> On 11/10/15, 3:38 PM, "Harsha" <ma...@harsha.io> wrote:
>
> >Thanks Taylor for putting together plan on merging JStorm code.
> >Few things
> >
> >1. we should call 0.11.0 as 1.0.0 release since storm has security and
> > nimbus ha . Quite a lot of features and improvements added this is
> > going to be big release and its about time we call 1.0.0
> >
> >1.1 "align package names (e.g backtype.storm --> org.apache.storm /
> >com.alibaba.jstorm --> org.apache.storm) (Phase 3 can begin" I
> >propose we do this as next release itself instead of pushing it
> >onto another .
> >
> >"Phase 3 - Migrate Clojure --> Java"
> >
> >I would like to propose a Hackathon among storm community along with
> >jstorm. We need to come up with plan of action on what code needs to be
> >merged into storm-core. I am thinking it will help better to have
> >everyone over video chat or something to go over the code and get it
> >migrated to java.
> >
> >
> >Thanks, Harsha
> >
> >On Tue, Nov 10, 2015, at 01:32 PM, P. Taylor Goetz wrote:
> >> Based on a number of discussions regarding merging the JStorm code,
> >> I¹ve tried to distill the ideas presented and inserted some of my own.
> >> The result is below.
> >>
> >> I¹ve divided the plan into three phases, though they are not
> >> necessarily sequential ‹ obviously some tasks can take place in
> >> parallel.
> >>
> >> None of this is set in stone, just presented for discussion. Any and
> >> all comments are welcome.
> >>
> >> -------
> >>
> >> Phase 1 - Plan for 0.11.x Release
> >> 1. Determine feature set for 0.11.x and publish to wiki [1].
> >> 2. Announce feature-freeze for 0.11.x
> >> 3. Create 0.11.x branch from master (Phase 2.4 can begin.)
> >> 4. Release 0.11.0 (or whatever version # we want to use)
> >> 5. Bug fixes and subsequent releases from 0.11.x-branch
> >>
> >>
> >> Phase 2 - Prepare for Merge ("master" and "jstorm-import" branches)
> >> 1. Determine/document unique features in JStorm (e.g. classpath
> >> isolation, cgroups, etc.) and create JIRA for migrating the
> >> feature.
> >> 2. Create JIRA for migrating each clojure component (or logical group
> >> of components) to Java. Assumes tests will be ported as well.
> >> 3. Discuss/establish style guide for Java coding conventions. Consider
> >> using Oracle¹s or Google¹s Java conventions as a base ‹ they are
> >> both pretty solid.
> >> 4. align package names (e.g backtype.storm --> org.apache.storm /
> >> com.alibaba.jstorm --> org.apache.storm) (Phase 3 can begin)
> >>
> >>
> >> Phase 3 - Migrate Clojure --> Java
> >> 1. Port code/tests to Java, leveraging existing JStorm code wherever
> >> possible (core functionality only, features distinct to JStorm
> >> migrated separately).
> >> 2. Port JStorm-specific features.
> >> 3. Begin releasing preview/beta versions.
> >> 4. Code cleanup (across the board) and refactoring using established
> >> coding conventions, and leveraging PMD/Checkstyle reports for
> >> reference. (Note: good oportunity for new contributors.)
> >> 5. Release 0.12.0 (or whatever version # we want to use) and lift
> >> feature freeze.
> >>
> >>
> >> Notes: We should consider bumping up to version 1.0 sometime soon and
> >> then switching to semantic versioning [3] from then on.
> >>
> >>
> >> With the exception of package name alignment, the "jstorm-import"
> >> branch will largely be read-only throughout the process.
> >>
> >> During migration, it's probably easiest to operate with two local
> >> clones of the Apache Storm repo: one for working (i.e. checked out to
> >> working branch) and one for reference/copying (i.e. checked out to
> >>"jstorm-
> >> import").
> >>
> >> Feature-freeze probably only needs to be enforced against core
> >> functionality. Components under "external" can likely be exempt, but
> >> we should figure out a process for accepting and releasing new
> >> features during the migration.
> >>
> >> Performance testing should be continuous throughout the process. Since
> >> we don't really have ASF infrastructure for performance testing, we
> >> will need a volunteer(s) to host and run the performance tests.
> >> Performance test results can be posted to the wiki [2]. It would
> >> probably be a good idea to establish a baseline with the 0.10.0
> >> release.
> >>
> >> I¹ve attached an analysis document Sean Zhong put together a while
> >> back to the JStorm merge JIRA [4]. The analysis was against the 0.9.3
> >> release but is still relevant and has a lot of good information.
> >>
> >>
> >> [1]
> >>
> https://cwiki.apache.org/confluence/display/STORM/Release+0.11.0+Feature+
> >>Set
> >> [2] https://cwiki.apache.org/confluence/display/STORM/Storm+Home
> >> [3]http://semver.org
> >> [4]https://issues.apache.org/jira/browse/STORM-717
> >>
> >>
> >> -Taylor
> >>
> >> Email had 1 attachment:
> >
> >
> >> * signature.asc 1k (application/pgp-signature)
>
>
Re: [DISCUSS] Plan for Merging JStorm Code
Posted by Cody Innowhere <e....@gmail.com>.
Thanks Taylor.
The plan looks good.
> During migration, it's probably easiest to operate with two local clones
of the Apache Storm repo: one for working (i.e. checked out to working
branch) > and one for reference/copying (i.e. checked out to
"jstorm-import").
Do you mean two storm branches(both clojure core) or one storm branch with
one JStorm-imported branch?
Tong.Wang is responsible for integration tests of JStorm, @Tong.Wang, could
you see to it if you can do the performace test?
On Wed, Nov 11, 2015 at 8:00 AM, Suresh Srinivas <su...@hortonworks.com>
wrote:
> +1 for 1.0.0 release.
>
> I also like Hackathon to encourage bigger participation. It will be fun.
>
> On 11/10/15, 3:38 PM, "Harsha" <ma...@harsha.io> wrote:
>
> >Thanks Taylor for putting together plan on merging JStorm code.
> >Few things
> >
> >1. we should call 0.11.0 as 1.0.0 release since storm has security and
> > nimbus ha . Quite a lot of features and improvements added this is
> > going to be big release and its about time we call 1.0.0
> >
> >1.1 "align package names (e.g backtype.storm --> org.apache.storm /
> >com.alibaba.jstorm --> org.apache.storm) (Phase 3 can begin" I
> >propose we do this as next release itself instead of pushing it
> >onto another .
> >
> >"Phase 3 - Migrate Clojure --> Java"
> >
> >I would like to propose a Hackathon among storm community along with
> >jstorm. We need to come up with plan of action on what code needs to be
> >merged into storm-core. I am thinking it will help better to have
> >everyone over video chat or something to go over the code and get it
> >migrated to java.
> >
> >
> >Thanks, Harsha
> >
> >On Tue, Nov 10, 2015, at 01:32 PM, P. Taylor Goetz wrote:
> >> Based on a number of discussions regarding merging the JStorm code,
> >> I¹ve tried to distill the ideas presented and inserted some of my own.
> >> The result is below.
> >>
> >> I¹ve divided the plan into three phases, though they are not
> >> necessarily sequential ‹ obviously some tasks can take place in
> >> parallel.
> >>
> >> None of this is set in stone, just presented for discussion. Any and
> >> all comments are welcome.
> >>
> >> -------
> >>
> >> Phase 1 - Plan for 0.11.x Release
> >> 1. Determine feature set for 0.11.x and publish to wiki [1].
> >> 2. Announce feature-freeze for 0.11.x
> >> 3. Create 0.11.x branch from master (Phase 2.4 can begin.)
> >> 4. Release 0.11.0 (or whatever version # we want to use)
> >> 5. Bug fixes and subsequent releases from 0.11.x-branch
> >>
> >>
> >> Phase 2 - Prepare for Merge ("master" and "jstorm-import" branches)
> >> 1. Determine/document unique features in JStorm (e.g. classpath
> >> isolation, cgroups, etc.) and create JIRA for migrating the
> >> feature.
> >> 2. Create JIRA for migrating each clojure component (or logical group
> >> of components) to Java. Assumes tests will be ported as well.
> >> 3. Discuss/establish style guide for Java coding conventions. Consider
> >> using Oracle¹s or Google¹s Java conventions as a base ‹ they are
> >> both pretty solid.
> >> 4. align package names (e.g backtype.storm --> org.apache.storm /
> >> com.alibaba.jstorm --> org.apache.storm) (Phase 3 can begin)
> >>
> >>
> >> Phase 3 - Migrate Clojure --> Java
> >> 1. Port code/tests to Java, leveraging existing JStorm code wherever
> >> possible (core functionality only, features distinct to JStorm
> >> migrated separately).
> >> 2. Port JStorm-specific features.
> >> 3. Begin releasing preview/beta versions.
> >> 4. Code cleanup (across the board) and refactoring using established
> >> coding conventions, and leveraging PMD/Checkstyle reports for
> >> reference. (Note: good oportunity for new contributors.)
> >> 5. Release 0.12.0 (or whatever version # we want to use) and lift
> >> feature freeze.
> >>
> >>
> >> Notes: We should consider bumping up to version 1.0 sometime soon and
> >> then switching to semantic versioning [3] from then on.
> >>
> >>
> >> With the exception of package name alignment, the "jstorm-import"
> >> branch will largely be read-only throughout the process.
> >>
> >> During migration, it's probably easiest to operate with two local
> >> clones of the Apache Storm repo: one for working (i.e. checked out to
> >> working branch) and one for reference/copying (i.e. checked out to
> >>"jstorm-
> >> import").
> >>
> >> Feature-freeze probably only needs to be enforced against core
> >> functionality. Components under "external" can likely be exempt, but
> >> we should figure out a process for accepting and releasing new
> >> features during the migration.
> >>
> >> Performance testing should be continuous throughout the process. Since
> >> we don't really have ASF infrastructure for performance testing, we
> >> will need a volunteer(s) to host and run the performance tests.
> >> Performance test results can be posted to the wiki [2]. It would
> >> probably be a good idea to establish a baseline with the 0.10.0
> >> release.
> >>
> >> I¹ve attached an analysis document Sean Zhong put together a while
> >> back to the JStorm merge JIRA [4]. The analysis was against the 0.9.3
> >> release but is still relevant and has a lot of good information.
> >>
> >>
> >> [1]
> >>
> https://cwiki.apache.org/confluence/display/STORM/Release+0.11.0+Feature+
> >>Set
> >> [2] https://cwiki.apache.org/confluence/display/STORM/Storm+Home
> >> [3]http://semver.org
> >> [4]https://issues.apache.org/jira/browse/STORM-717
> >>
> >>
> >> -Taylor
> >>
> >> Email had 1 attachment:
> >
> >
> >> * signature.asc 1k (application/pgp-signature)
>
>
Re: [DISCUSS] Plan for Merging JStorm Code
Posted by Suresh Srinivas <su...@hortonworks.com>.
+1 for 1.0.0 release.
I also like Hackathon to encourage bigger participation. It will be fun.
On 11/10/15, 3:38 PM, "Harsha" <ma...@harsha.io> wrote:
>Thanks Taylor for putting together plan on merging JStorm code.
>Few things
>
>1. we should call 0.11.0 as 1.0.0 release since storm has security and
> nimbus ha . Quite a lot of features and improvements added this is
> going to be big release and its about time we call 1.0.0
>
>1.1 "align package names (e.g backtype.storm --> org.apache.storm /
>com.alibaba.jstorm --> org.apache.storm) (Phase 3 can begin" I
>propose we do this as next release itself instead of pushing it
>onto another .
>
>"Phase 3 - Migrate Clojure --> Java"
>
>I would like to propose a Hackathon among storm community along with
>jstorm. We need to come up with plan of action on what code needs to be
>merged into storm-core. I am thinking it will help better to have
>everyone over video chat or something to go over the code and get it
>migrated to java.
>
>
>Thanks, Harsha
>
>On Tue, Nov 10, 2015, at 01:32 PM, P. Taylor Goetz wrote:
>> Based on a number of discussions regarding merging the JStorm code,
>> I¹ve tried to distill the ideas presented and inserted some of my own.
>> The result is below.
>>
>> I¹ve divided the plan into three phases, though they are not
>> necessarily sequential ‹ obviously some tasks can take place in
>> parallel.
>>
>> None of this is set in stone, just presented for discussion. Any and
>> all comments are welcome.
>>
>> -------
>>
>> Phase 1 - Plan for 0.11.x Release
>> 1. Determine feature set for 0.11.x and publish to wiki [1].
>> 2. Announce feature-freeze for 0.11.x
>> 3. Create 0.11.x branch from master (Phase 2.4 can begin.)
>> 4. Release 0.11.0 (or whatever version # we want to use)
>> 5. Bug fixes and subsequent releases from 0.11.x-branch
>>
>>
>> Phase 2 - Prepare for Merge ("master" and "jstorm-import" branches)
>> 1. Determine/document unique features in JStorm (e.g. classpath
>> isolation, cgroups, etc.) and create JIRA for migrating the
>> feature.
>> 2. Create JIRA for migrating each clojure component (or logical group
>> of components) to Java. Assumes tests will be ported as well.
>> 3. Discuss/establish style guide for Java coding conventions. Consider
>> using Oracle¹s or Google¹s Java conventions as a base ‹ they are
>> both pretty solid.
>> 4. align package names (e.g backtype.storm --> org.apache.storm /
>> com.alibaba.jstorm --> org.apache.storm) (Phase 3 can begin)
>>
>>
>> Phase 3 - Migrate Clojure --> Java
>> 1. Port code/tests to Java, leveraging existing JStorm code wherever
>> possible (core functionality only, features distinct to JStorm
>> migrated separately).
>> 2. Port JStorm-specific features.
>> 3. Begin releasing preview/beta versions.
>> 4. Code cleanup (across the board) and refactoring using established
>> coding conventions, and leveraging PMD/Checkstyle reports for
>> reference. (Note: good oportunity for new contributors.)
>> 5. Release 0.12.0 (or whatever version # we want to use) and lift
>> feature freeze.
>>
>>
>> Notes: We should consider bumping up to version 1.0 sometime soon and
>> then switching to semantic versioning [3] from then on.
>>
>>
>> With the exception of package name alignment, the "jstorm-import"
>> branch will largely be read-only throughout the process.
>>
>> During migration, it's probably easiest to operate with two local
>> clones of the Apache Storm repo: one for working (i.e. checked out to
>> working branch) and one for reference/copying (i.e. checked out to
>>"jstorm-
>> import").
>>
>> Feature-freeze probably only needs to be enforced against core
>> functionality. Components under "external" can likely be exempt, but
>> we should figure out a process for accepting and releasing new
>> features during the migration.
>>
>> Performance testing should be continuous throughout the process. Since
>> we don't really have ASF infrastructure for performance testing, we
>> will need a volunteer(s) to host and run the performance tests.
>> Performance test results can be posted to the wiki [2]. It would
>> probably be a good idea to establish a baseline with the 0.10.0
>> release.
>>
>> I¹ve attached an analysis document Sean Zhong put together a while
>> back to the JStorm merge JIRA [4]. The analysis was against the 0.9.3
>> release but is still relevant and has a lot of good information.
>>
>>
>> [1]
>>https://cwiki.apache.org/confluence/display/STORM/Release+0.11.0+Feature+
>>Set
>> [2] https://cwiki.apache.org/confluence/display/STORM/Storm+Home
>> [3]http://semver.org
>> [4]https://issues.apache.org/jira/browse/STORM-717
>>
>>
>> -Taylor
>>
>> Email had 1 attachment:
>
>
>> * signature.asc 1k (application/pgp-signature)
Re: [DISCUSS] Plan for Merging JStorm Code
Posted by Harsha <ma...@harsha.io>.
Thanks Taylor for putting together plan on merging JStorm code.
Few things
1. we should call 0.11.0 as 1.0.0 release since storm has security and
nimbus ha . Quite a lot of features and improvements added this is
going to be big release and its about time we call 1.0.0
1.1 "align package names (e.g backtype.storm --> org.apache.storm /
com.alibaba.jstorm --> org.apache.storm) (Phase 3 can begin" I
propose we do this as next release itself instead of pushing it
onto another .
"Phase 3 - Migrate Clojure --> Java"
I would like to propose a Hackathon among storm community along with
jstorm. We need to come up with plan of action on what code needs to be
merged into storm-core. I am thinking it will help better to have
everyone over video chat or something to go over the code and get it
migrated to java.
Thanks, Harsha
On Tue, Nov 10, 2015, at 01:32 PM, P. Taylor Goetz wrote:
> Based on a number of discussions regarding merging the JStorm code,
> I’ve tried to distill the ideas presented and inserted some of my own.
> The result is below.
>
> I’ve divided the plan into three phases, though they are not
> necessarily sequential — obviously some tasks can take place in
> parallel.
>
> None of this is set in stone, just presented for discussion. Any and
> all comments are welcome.
>
> -------
>
> Phase 1 - Plan for 0.11.x Release
> 1. Determine feature set for 0.11.x and publish to wiki [1].
> 2. Announce feature-freeze for 0.11.x
> 3. Create 0.11.x branch from master (Phase 2.4 can begin.)
> 4. Release 0.11.0 (or whatever version # we want to use)
> 5. Bug fixes and subsequent releases from 0.11.x-branch
>
>
> Phase 2 - Prepare for Merge ("master" and "jstorm-import" branches)
> 1. Determine/document unique features in JStorm (e.g. classpath
> isolation, cgroups, etc.) and create JIRA for migrating the
> feature.
> 2. Create JIRA for migrating each clojure component (or logical group
> of components) to Java. Assumes tests will be ported as well.
> 3. Discuss/establish style guide for Java coding conventions. Consider
> using Oracle’s or Google’s Java conventions as a base — they are
> both pretty solid.
> 4. align package names (e.g backtype.storm --> org.apache.storm /
> com.alibaba.jstorm --> org.apache.storm) (Phase 3 can begin)
>
>
> Phase 3 - Migrate Clojure --> Java
> 1. Port code/tests to Java, leveraging existing JStorm code wherever
> possible (core functionality only, features distinct to JStorm
> migrated separately).
> 2. Port JStorm-specific features.
> 3. Begin releasing preview/beta versions.
> 4. Code cleanup (across the board) and refactoring using established
> coding conventions, and leveraging PMD/Checkstyle reports for
> reference. (Note: good oportunity for new contributors.)
> 5. Release 0.12.0 (or whatever version # we want to use) and lift
> feature freeze.
>
>
> Notes: We should consider bumping up to version 1.0 sometime soon and
> then switching to semantic versioning [3] from then on.
>
>
> With the exception of package name alignment, the "jstorm-import"
> branch will largely be read-only throughout the process.
>
> During migration, it's probably easiest to operate with two local
> clones of the Apache Storm repo: one for working (i.e. checked out to
> working branch) and one for reference/copying (i.e. checked out to "jstorm-
> import").
>
> Feature-freeze probably only needs to be enforced against core
> functionality. Components under "external" can likely be exempt, but
> we should figure out a process for accepting and releasing new
> features during the migration.
>
> Performance testing should be continuous throughout the process. Since
> we don't really have ASF infrastructure for performance testing, we
> will need a volunteer(s) to host and run the performance tests.
> Performance test results can be posted to the wiki [2]. It would
> probably be a good idea to establish a baseline with the 0.10.0
> release.
>
> I’ve attached an analysis document Sean Zhong put together a while
> back to the JStorm merge JIRA [4]. The analysis was against the 0.9.3
> release but is still relevant and has a lot of good information.
>
>
> [1] https://cwiki.apache.org/confluence/display/STORM/Release+0.11.0+Feature+Set
> [2] https://cwiki.apache.org/confluence/display/STORM/Storm+Home
> [3]http://semver.org
> [4]https://issues.apache.org/jira/browse/STORM-717
>
>
> -Taylor
>
> Email had 1 attachment:
> * signature.asc 1k (application/pgp-signature)