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/11 23:21:50 UTC
[DISCUSS] 1.0 Release (was Re: [DISCUSS] Initial 0.11.0 Release)
Changing subject in order to consolidate discussion of a 1.0 release in one thread (there was some additional discussion in the thread regarding the JStorm code merge).
I just want to make sure I’m accurately capturing the sentiment of the community with regard to a 1.0 release. Please correct me if my summary seems off-base or jump in with an opinion.
In summary:
1. What we have been calling “0.11.0” will become the Storm 1.0 release.
2. We will NOT be migrating package names for this release (i.e. “backtype.storm” —> “org.apache.storm”).
3. Post 1.0 release we will go into feature freeze for core functionality to facilitate the JStorm merge.
4. During the feature freeze only fixes for high priority bugs in core functionality will be accepted (no new features).
5. During the feature freeze, enhancements to “external” modules can be accepted.
6. We will stop using the “beta” flag in favor of purely numeric version numbers. Stable vs. non-stable (development) releases can be indicated on the download page.
Do we all agree?
-Taylor
> On Nov 11, 2015, at 4:10 PM, P. Taylor Goetz <pt...@gmail.com> wrote:
>
>
>> On Nov 11, 2015, at 9:28 AM, Bobby Evans <ev...@yahoo-inc.com.INVALID> wrote:
>>
>> I would like to see STORM-1190, STORM-1155, STORM-1198, STORM-1196, STORM-885, STORM-876, STORM-1145, STORM-831, and STORM-874 added to the list.
>>
>> Some of them are more important then others but they are all things I would like to see in a 0.11.0 release.
>
>
> Cool. Thanks for listing them out. I will add them so they get tracked.
>
>
>> On a side note I don't think the beta releases have been helpful. I would much rather just have a 0.11.0 go to 0.11.1 ... instead of 0.11.0-beta1, 0.11.0-beta2. To me the beta label is not that helpful, but it is not that big of a deal for me.
>
> In my mind, having releases tagged as “beta” were a way for us to say to users “here’s a preview release that will allow you to kick the tires on upcoming features, but be aware that there might be bugs. Let us know if you find any so we can fix them.”
>
> I think the intent was sound, but what I didn’t really see was user feedback on the beta releases, which is what I hoped would happen. So I have no problem with dropping the use of “beta” flags.
>
> Another approach I’ve seen other Apache projects use is to the numbering scheme you describe, and just have different labels/descriptions on the download page — i.e. “Latest stable release” and “Latest development release.” The nice part of that convention is that it does not have any impact on the release process. For example if we’re confident that a particular “development” release is actually quite stable, all we would have to do is update the downloads page, rather than go through the whole release/vote process just to remove the “beta” tag.
>
>> I also would like to see the 0.11 release tied to the plan for the JStorm merger. If we don't tie them together there can be code that does not make it into 0.11, but could make it into a 0.12 that will immediately be caught up in the merger, that could take a long time to complete. I mostly want us to be very transparent about what is likely to happen after 0.11 is released. So if someone has a feature that is close to getting something in to 0.11 that they speak up here instead of just deciding to wait for a 0.12 release.
>
>
> I agree that the 0.11 release needs to be tied to the JStorm merger. Once that release goes out, we’ll be going into lockdown mode for the merge effort, which is likely to take a while.
>
> During that time it’s highly unlikely that any changes/additions to Storm’s core functionality will be accepted beyond high-priority bug fixes. Adding new features to the “external” components during that time is probably okay, since those components are sufficiently decoupled from Storm’s core functionality.
>
> So to reiterate Bobby’s statement:
>
> Please speak up now if there are any specific features or changes to Storm’s core functionality that you’d like to see in the next release. Otherwise you will have to wait.
>
>> - Bobby
>
> -Taylor
>
>>
>>
>> On Wednesday, November 11, 2015 6:32 AM, John Fang <xi...@alibaba-inc.com> wrote:
>>
>>
>> Totally agree， it's great to accelerate the release speed. it is better release one official version within 3 months. The first month is for developing new features , .If some features hasn't been finished in this month, it will be put in the next release ticket. In the last two month, we just do test.
>> Storm may face the greatest challenge in a big cluster, so I am more concerned about ZK Optimization as jstorm did. At last, it's great for the next release to has a test report about the stability and performance , due to lots of new features in the latest versions.
>>
>> Regards
>> John Fang
>>
>> -----邮件原件-----
>> 发件人: P. Taylor Goetz [mailto:ptgoetz@gmail.com]
>> 发送时间: 2015年11月11日 6:16
>> 收件人: dev@storm.apache.org
>> 主题: [DISCUSS] Initial 0.11.0 Release
>>
>> I’d like to start discussing our next release (0.11.0).
>>
>> First off, I’d like to create a list of issues/features that are in-progress and not yet merged to master, so we can start tracking them for inclusion in the release. If there are specific JIRAs you would like included, please reply, and I will add them to the wiki page for the 0.11.0 release [1].
>>
>> Second, I’d like to propose modifying the release cycle a bit. I’d like to continue the beta release cycle we started with 0.10.0, but this time I’d like to consider adding some sort of temporal constraint so we release new betas more often — something like a new beta release every 3 weeks or so until we feel confident in dropping the beta tag. IMHO, there was too long a gap between 0.10.0-beta1 and 0.10.0 and we should have had more interim releases during that time.
>>
>> Any thoughts?
>>
>> -Taylor
>>
>> [1] https://cwiki.apache.org/confluence/display/STORM/Release+0.11.0+Feature+Set
>>
>>
>
Re: [DISCUSS] 1.0 Release (was Re: [DISCUSS] Initial 0.11.0
Release)
Posted by Bobby Evans <ev...@yahoo-inc.com.INVALID>.
+1 - Bobby
On Wednesday, November 11, 2015 4:22 PM, P. Taylor Goetz <pt...@gmail.com> wrote:
Changing subject in order to consolidate discussion of a 1.0 release in one thread (there was some additional discussion in the thread regarding the JStorm code merge).
I just want to make sure I’m accurately capturing the sentiment of the community with regard to a 1.0 release. Please correct me if my summary seems off-base or jump in with an opinion.
In summary:
1. What we have been calling “0.11.0” will become the Storm 1.0 release.
2. We will NOT be migrating package names for this release (i.e. “backtype.storm” —> “org.apache.storm”).
3. Post 1.0 release we will go into feature freeze for core functionality to facilitate the JStorm merge.
4. During the feature freeze only fixes for high priority bugs in core functionality will be accepted (no new features).
5. During the feature freeze, enhancements to “external” modules can be accepted.
6. We will stop using the “beta” flag in favor of purely numeric version numbers. Stable vs. non-stable (development) releases can be indicated on the download page.
Do we all agree?
-Taylor
> On Nov 11, 2015, at 4:10 PM, P. Taylor Goetz <pt...@gmail.com> wrote:
>
>
>> On Nov 11, 2015, at 9:28 AM, Bobby Evans <ev...@yahoo-inc.com.INVALID> wrote:
>>
>> I would like to see STORM-1190, STORM-1155, STORM-1198, STORM-1196, STORM-885, STORM-876, STORM-1145, STORM-831, and STORM-874 added to the list.
>>
>> Some of them are more important then others but they are all things I would like to see in a 0.11.0 release.
>
>
> Cool. Thanks for listing them out. I will add them so they get tracked.
>
>
>> On a side note I don't think the beta releases have been helpful. I would much rather just have a 0.11.0 go to 0.11.1 ... instead of 0.11.0-beta1, 0.11.0-beta2. To me the beta label is not that helpful, but it is not that big of a deal for me.
>
> In my mind, having releases tagged as “beta” were a way for us to say to users “here’s a preview release that will allow you to kick the tires on upcoming features, but be aware that there might be bugs. Let us know if you find any so we can fix them.”
>
> I think the intent was sound, but what I didn’t really see was user feedback on the beta releases, which is what I hoped would happen. So I have no problem with dropping the use of “beta” flags.
>
> Another approach I’ve seen other Apache projects use is to the numbering scheme you describe, and just have different labels/descriptions on the download page — i.e. “Latest stable release” and “Latest development release.” The nice part of that convention is that it does not have any impact on the release process. For example if we’re confident that a particular “development” release is actually quite stable, all we would have to do is update the downloads page, rather than go through the whole release/vote process just to remove the “beta” tag.
>
>> I also would like to see the 0.11 release tied to the plan for the JStorm merger. If we don't tie them together there can be code that does not make it into 0.11, but could make it into a 0.12 that will immediately be caught up in the merger, that could take a long time to complete. I mostly want us to be very transparent about what is likely to happen after 0.11 is released. So if someone has a feature that is close to getting something in to 0.11 that they speak up here instead of just deciding to wait for a 0.12 release.
>
>
> I agree that the 0.11 release needs to be tied to the JStorm merger. Once that release goes out, we’ll be going into lockdown mode for the merge effort, which is likely to take a while.
>
> During that time it’s highly unlikely that any changes/additions to Storm’s core functionality will be accepted beyond high-priority bug fixes. Adding new features to the “external” components during that time is probably okay, since those components are sufficiently decoupled from Storm’s core functionality.
>
> So to reiterate Bobby’s statement:
>
> Please speak up now if there are any specific features or changes to Storm’s core functionality that you’d like to see in the next release. Otherwise you will have to wait.
>
>> - Bobby
>
> -Taylor
>
>>
>>
>> On Wednesday, November 11, 2015 6:32 AM, John Fang <xi...@alibaba-inc.com> wrote:
>>
>>
>> Totally agree， it's great to accelerate the release speed. it is better release one official version within 3 months. The first month is for developing new features , .If some features hasn't been finished in this month, it will be put in the next release ticket. In the last two month, we just do test.
>> Storm may face the greatest challenge in a big cluster, so I am more concerned about ZK Optimization as jstorm did. At last, it's great for the next release to has a test report about the stability and performance , due to lots of new features in the latest versions.
>>
>> Regards
>> John Fang
>>
>> -----邮件原件-----
>> 发件人: P. Taylor Goetz [mailto:ptgoetz@gmail.com]
>> 发送时间: 2015年11月11日 6:16
>> 收件人: dev@storm.apache.org
>> 主题: [DISCUSS] Initial 0.11.0 Release
>>
>> I’d like to start discussing our next release (0.11.0).
>>
>> First off, I’d like to create a list of issues/features that are in-progress and not yet merged to master, so we can start tracking them for inclusion in the release. If there are specific JIRAs you would like included, please reply, and I will add them to the wiki page for the 0.11.0 release [1].
>>
>> Second, I’d like to propose modifying the release cycle a bit. I’d like to continue the beta release cycle we started with 0.10.0, but this time I’d like to consider adding some sort of temporal constraint so we release new betas more often — something like a new beta release every 3 weeks or so until we feel confident in dropping the beta tag. IMHO, there was too long a gap between 0.10.0-beta1 and 0.10.0 and we should have had more interim releases during that time.
>>
>> Any thoughts?
>>
>> -Taylor
>>
>> [1] https://cwiki.apache.org/confluence/display/STORM/Release+0.11.0+Feature+Set
>>
>>
>
Re: [DISCUSS] 1.0 Release (was Re: [DISCUSS] Initial 0.11.0
Release)
Posted by Parth Brahmbhatt <pb...@hortonworks.com>.
+1.
On 11/11/15, 2:27 PM, "Derek Dagit" <de...@yahoo-inc.com.INVALID> wrote:
>+1
>
> --
>Derek
>
>
>----- Original Message -----
>From: P. Taylor Goetz <pt...@gmail.com>
>To: dev@storm.apache.org
>Cc:
>Sent: Wednesday, November 11, 2015 4:21 PM
>Subject: [DISCUSS] 1.0 Release (was Re: [DISCUSS] Initial 0.11.0 Release)
>
>Changing subject in order to consolidate discussion of a 1.0 release in
>one thread (there was some additional discussion in the thread regarding
>the JStorm code merge).
>
>I just want to make sure I’m accurately capturing the sentiment of the
>community with regard to a 1.0 release. Please correct me if my summary
>seems off-base or jump in with an opinion.
>
>In summary:
>
>1. What we have been calling “0.11.0” will become the Storm 1.0 release.
>2. We will NOT be migrating package names for this release (i.e.
>“backtype.storm” ―> “org.apache.storm”).
>3. Post 1.0 release we will go into feature freeze for core functionality
>to facilitate the JStorm merge.
>4. During the feature freeze only fixes for high priority bugs in core
>functionality will be accepted (no new features).
>5. During the feature freeze, enhancements to “external” modules can be
>accepted.
>6. We will stop using the “beta” flag in favor of purely numeric version
>numbers. Stable vs. non-stable (development) releases can be indicated on
>the download page.
>
>Do we all agree?
>
>-Taylor
>
>
>> On Nov 11, 2015, at 4:10 PM, P. Taylor Goetz <pt...@gmail.com> wrote:
>>
>>
>>> On Nov 11, 2015, at 9:28 AM, Bobby Evans <ev...@yahoo-inc.com.INVALID>
>>>wrote:
>>>
>>> I would like to see STORM-1190, STORM-1155, STORM-1198, STORM-1196,
>>>STORM-885, STORM-876, STORM-1145, STORM-831, and STORM-874 added to the
>>>list.
>>>
>>> Some of them are more important then others but they are all things I
>>>would like to see in a 0.11.0 release.
>>
>>
>> Cool. Thanks for listing them out. I will add them so they get tracked.
>>
>>
>>> On a side note I don't think the beta releases have been helpful. I
>>>would much rather just have a 0.11.0 go to 0.11.1 ... instead of
>>>0.11.0-beta1, 0.11.0-beta2. To me the beta label is not that helpful,
>>>but it is not that big of a deal for me.
>>
>> In my mind, having releases tagged as “beta” were a way for us to say
>>to users “here’s a preview release that will allow you to kick the tires
>>on upcoming features, but be aware that there might be bugs. Let us know
>>if you find any so we can fix them.”
>>
>> I think the intent was sound, but what I didn’t really see was user
>>feedback on the beta releases, which is what I hoped would happen. So I
>>have no problem with dropping the use of “beta” flags.
>>
>> Another approach I’ve seen other Apache projects use is to the
>>numbering scheme you describe, and just have different
>>labels/descriptions on the download page ― i.e. “Latest stable release”
>>and “Latest development release.” The nice part of that convention is
>>that it does not have any impact on the release process. For example if
>>we’re confident that a particular “development” release is actually
>>quite stable, all we would have to do is update the downloads page,
>>rather than go through the whole release/vote process just to remove the
>>“beta” tag.
>>
>>> I also would like to see the 0.11 release tied to the plan for the
>>>JStorm merger. If we don't tie them together there can be code that
>>>does not make it into 0.11, but could make it into a 0.12 that will
>>>immediately be caught up in the merger, that could take a long time to
>>>complete. I mostly want us to be very transparent about what is likely
>>>to happen after 0.11 is released. So if someone has a feature that is
>>>close to getting something in to 0.11 that they speak up here instead
>>>of just deciding to wait for a 0.12 release.
>>
>>
>> I agree that the 0.11 release needs to be tied to the JStorm merger.
>>Once that release goes out, we’ll be going into lockdown mode for the
>>merge effort, which is likely to take a while.
>>
>> During that time it’s highly unlikely that any changes/additions to
>>Storm’s core functionality will be accepted beyond high-priority bug
>>fixes. Adding new features to the “external” components during that time
>>is probably okay, since those components are sufficiently decoupled from
>>Storm’s core functionality.
>>
>> So to reiterate Bobby’s statement:
>>
>> Please speak up now if there are any specific features or changes to
>>Storm’s core functionality that you’d like to see in the next release.
>>Otherwise you will have to wait.
>>
>>> - Bobby
>>
>> -Taylor
>>
>>>
>>>
>>> On Wednesday, November 11, 2015 6:32 AM, John Fang
>>><xi...@alibaba-inc.com> wrote:
>>>
>>>
>>> Totally agree， it's great to accelerate the release speed. it is
>>>better release one official version within 3 months. The first month is
>>>for developing new features , .If some features hasn't been finished in
>>>this month, it will be put in the next release ticket. In the last two
>>>month, we just do test.
>>> Storm may face the greatest challenge in a big cluster, so I am more
>>>concerned about ZK Optimization as jstorm did. At last, it's great for
>>>the next release to has a test report about the stability and
>>>performance , due to lots of new features in the latest versions.
>>>
>>> Regards
>>> John Fang
>>>
>>> -----邮件原件-----
>>> 发件人: P. Taylor Goetz [mailto:ptgoetz@gmail.com]
>>> 发送时间: 2015年11月11日 6:16
>>> 收件人: dev@storm.apache.org
>>> 主题: [DISCUSS] Initial 0.11.0 Release
>>>
>>> I’d like to start discussing our next release (0.11.0).
>>>
>>> First off, I’d like to create a list of issues/features that are
>>>in-progress and not yet merged to master, so we can start tracking them
>>>for inclusion in the release. If there are specific JIRAs you would
>>>like included, please reply, and I will add them to the wiki page for
>>>the 0.11.0 release [1].
>>>
>>> Second, I’d like to propose modifying the release cycle a bit. I’d
>>>like to continue the beta release cycle we started with 0.10.0, but
>>>this time I’d like to consider adding some sort of temporal constraint
>>>so we release new betas more often ― something like a new beta release
>>>every 3 weeks or so until we feel confident in dropping the beta tag.
>>>IMHO, there was too long a gap between 0.10.0-beta1 and 0.10.0 and we
>>>should have had more interim releases during that time.
>>>
>>> Any thoughts?
>>>
>>> -Taylor
>>>
>>> [1]
>>>https://cwiki.apache.org/confluence/display/STORM/Release+0.11.0+Feature
>>>+Set
>>>
>>>
>>
>
Re: [DISCUSS] 1.0 Release (was Re: [DISCUSS] Initial 0.11.0
Release)
Posted by Derek Dagit <de...@yahoo-inc.com.INVALID>.
+1
--
Derek
----- Original Message -----
From: P. Taylor Goetz <pt...@gmail.com>
To: dev@storm.apache.org
Cc:
Sent: Wednesday, November 11, 2015 4:21 PM
Subject: [DISCUSS] 1.0 Release (was Re: [DISCUSS] Initial 0.11.0 Release)
Changing subject in order to consolidate discussion of a 1.0 release in one thread (there was some additional discussion in the thread regarding the JStorm code merge).
I just want to make sure I’m accurately capturing the sentiment of the community with regard to a 1.0 release. Please correct me if my summary seems off-base or jump in with an opinion.
In summary:
1. What we have been calling “0.11.0” will become the Storm 1.0 release.
2. We will NOT be migrating package names for this release (i.e. “backtype.storm” —> “org.apache.storm”).
3. Post 1.0 release we will go into feature freeze for core functionality to facilitate the JStorm merge.
4. During the feature freeze only fixes for high priority bugs in core functionality will be accepted (no new features).
5. During the feature freeze, enhancements to “external” modules can be accepted.
6. We will stop using the “beta” flag in favor of purely numeric version numbers. Stable vs. non-stable (development) releases can be indicated on the download page.
Do we all agree?
-Taylor
> On Nov 11, 2015, at 4:10 PM, P. Taylor Goetz <pt...@gmail.com> wrote:
>
>
>> On Nov 11, 2015, at 9:28 AM, Bobby Evans <ev...@yahoo-inc.com.INVALID> wrote:
>>
>> I would like to see STORM-1190, STORM-1155, STORM-1198, STORM-1196, STORM-885, STORM-876, STORM-1145, STORM-831, and STORM-874 added to the list.
>>
>> Some of them are more important then others but they are all things I would like to see in a 0.11.0 release.
>
>
> Cool. Thanks for listing them out. I will add them so they get tracked.
>
>
>> On a side note I don't think the beta releases have been helpful. I would much rather just have a 0.11.0 go to 0.11.1 ... instead of 0.11.0-beta1, 0.11.0-beta2. To me the beta label is not that helpful, but it is not that big of a deal for me.
>
> In my mind, having releases tagged as “beta” were a way for us to say to users “here’s a preview release that will allow you to kick the tires on upcoming features, but be aware that there might be bugs. Let us know if you find any so we can fix them.”
>
> I think the intent was sound, but what I didn’t really see was user feedback on the beta releases, which is what I hoped would happen. So I have no problem with dropping the use of “beta” flags.
>
> Another approach I’ve seen other Apache projects use is to the numbering scheme you describe, and just have different labels/descriptions on the download page — i.e. “Latest stable release” and “Latest development release.” The nice part of that convention is that it does not have any impact on the release process. For example if we’re confident that a particular “development” release is actually quite stable, all we would have to do is update the downloads page, rather than go through the whole release/vote process just to remove the “beta” tag.
>
>> I also would like to see the 0.11 release tied to the plan for the JStorm merger. If we don't tie them together there can be code that does not make it into 0.11, but could make it into a 0.12 that will immediately be caught up in the merger, that could take a long time to complete. I mostly want us to be very transparent about what is likely to happen after 0.11 is released. So if someone has a feature that is close to getting something in to 0.11 that they speak up here instead of just deciding to wait for a 0.12 release.
>
>
> I agree that the 0.11 release needs to be tied to the JStorm merger. Once that release goes out, we’ll be going into lockdown mode for the merge effort, which is likely to take a while.
>
> During that time it’s highly unlikely that any changes/additions to Storm’s core functionality will be accepted beyond high-priority bug fixes. Adding new features to the “external” components during that time is probably okay, since those components are sufficiently decoupled from Storm’s core functionality.
>
> So to reiterate Bobby’s statement:
>
> Please speak up now if there are any specific features or changes to Storm’s core functionality that you’d like to see in the next release. Otherwise you will have to wait.
>
>> - Bobby
>
> -Taylor
>
>>
>>
>> On Wednesday, November 11, 2015 6:32 AM, John Fang <xi...@alibaba-inc.com> wrote:
>>
>>
>> Totally agree， it's great to accelerate the release speed. it is better release one official version within 3 months. The first month is for developing new features , .If some features hasn't been finished in this month, it will be put in the next release ticket. In the last two month, we just do test.
>> Storm may face the greatest challenge in a big cluster, so I am more concerned about ZK Optimization as jstorm did. At last, it's great for the next release to has a test report about the stability and performance , due to lots of new features in the latest versions.
>>
>> Regards
>> John Fang
>>
>> -----邮件原件-----
>> 发件人: P. Taylor Goetz [mailto:ptgoetz@gmail.com]
>> 发送时间: 2015年11月11日 6:16
>> 收件人: dev@storm.apache.org
>> 主题: [DISCUSS] Initial 0.11.0 Release
>>
>> I’d like to start discussing our next release (0.11.0).
>>
>> First off, I’d like to create a list of issues/features that are in-progress and not yet merged to master, so we can start tracking them for inclusion in the release. If there are specific JIRAs you would like included, please reply, and I will add them to the wiki page for the 0.11.0 release [1].
>>
>> Second, I’d like to propose modifying the release cycle a bit. I’d like to continue the beta release cycle we started with 0.10.0, but this time I’d like to consider adding some sort of temporal constraint so we release new betas more often — something like a new beta release every 3 weeks or so until we feel confident in dropping the beta tag. IMHO, there was too long a gap between 0.10.0-beta1 and 0.10.0 and we should have had more interim releases during that time.
>>
>> Any thoughts?
>>
>> -Taylor
>>
>> [1] https://cwiki.apache.org/confluence/display/STORM/Release+0.11.0+Feature+Set
>>
>>
>
Re: [DISCUSS] 1.0 Release (was Re: [DISCUSS] Initial 0.11.0
Release)
Posted by Kyle Nusbaum <kn...@yahoo-inc.com.INVALID>.
I may have misunderstood.
I'm okay with cutting 1.0 if after we merge JStorm we go to 2.0.
I thought I read in one of these threads the proposal to move to 1.1 afterwards, but I cannot find it now.
-- Kyle
On Tuesday, November 17, 2015 5:00 PM, Kyle Nusbaum <kn...@yahoo-inc.com.INVALID> wrote:
I would prefer to wait until the JStorm code is merged to move to 1.0, and keep the current planned release as 0.11
My concern is that there will be significant functionality and possibly stability changes involved, and it feels more natural to have major changes be across a
major version release.
Rather than release 1.0 and then immediately make major changes to the project, I would propose we release 0.11, then do the freeze and merge the JStorm code, and the first release after that can be 1.0. -- Kyle
On Tuesday, November 17, 2015 1:57 PM, Bobby Evans <ev...@yahoo-inc.com.INVALID> wrote:
I have a pull request up now for these changes. I can run both new and old jars, but you have to use a new client when submitting an old jar or it will not work.
https://github.com/apache/storm/pull/889
- Bobby
On Tuesday, November 17, 2015 9:43 AM, Bobby Evans <ev...@yahoo-inc.com.INVALID> wrote:
I have a patch that is close, but like I said on the JIRA https://issues.apache.org/jira/browse/STORM-1202 we are not going to be able to make a storm-compat.jar work. Instead I have a binary that uses the shade code to rewrite the jar before it runs to match the new namespace. I am just doing some cleanup on the code and testing now before I put up the pull request either today or tomorrow. It too will be something that we can remove for a 2.0 release.
- Bobby
On Monday, November 16, 2015 7:23 PM, Harsha <st...@harsha.io> wrote:
+1 on Bobby's suggestion on moving the packages to storm-compat and have
it part of lib folder.
Moving 1.0 with org.apache.storm will make it easier in the future
rather than wait for 2.0 release we should make
this change now and in 2.0 we can remove the storm-compat jar.
Thanks,
Harsha
On Thu, Nov 12, 2015, at 07:15 AM, Bobby Evans wrote:
> I agree that having the old package names for a 1.0 release is a little
> odd, but I also am nervous about breaking backwards compatibility for our
> customers in a very significant way. The upgrade for us from 0.9.x to
> 0.10.x has gone fairly smoothly. Most customers read the announcement
> and recompiled their code against 0.10, but followed our instructions so
> that their topologies could run on both 0.9.x and 0.10.x. Having the
> ability for a topology to run on both an old cluster and a new cluster is
> very important for us, because of failover. If we want to minimize
> downtime we need to have the ability to fail a topology over from one
> cluster to another, usually running on the other side of the
> country/world. For stability reasons we do not want to upgrade both
> clusters at once, so we need to have confidence that a topology can run
> on both clusters. Maintaining two versions of a topology is a huge pain
> as well.
> Perhaps what we can do for 1.0 is to move all of the packages to
> org.apache.storm, but provide a storm-compat package that will still have
> the old user facing APIs in it, that are actually (for the most part)
> subclasses/interfaces of the org.apache versions. I am not sure this
> will work perfectly, but I think I will give it a try.
> - Bobby
>
>
> On Thursday, November 12, 2015 9:04 AM, Aaron. Dossett
> <Aa...@target.com> wrote:
>
>
> As a user/developer this sounds great. The only item that gives me
> pause
> is #2. Still seeing backtype.* package names would be unexpected (for
> me)
> for a 1.0 release. That small reservation aside, I am +1 (non-binding).
>
> On 11/11/15, 2:45 PM, "임정택" <ka...@gmail.com> wrote:
>
> >+1
> >
> >Jungtaek Lim (HeartSaVioR)
> >
> >2015-11-12 7:21 GMT+09:00 P. Taylor Goetz <pt...@gmail.com>:
> >
> >> Changing subject in order to consolidate discussion of a 1.0 release in
> >> one thread (there was some additional discussion in the thread regarding
> >> the JStorm code merge).
> >>
> >> I just want to make sure I’m accurately capturing the sentiment of the
> >> community with regard to a 1.0 release. Please correct me if my summary
> >> seems off-base or jump in with an opinion.
> >>
> >> In summary:
> >>
> >> 1. What we have been calling “0.11.0” will become the Storm 1.0 release.
> >> 2. We will NOT be migrating package names for this release (i.e.
> >> “backtype.storm” —> “org.apache.storm”).
> >> 3. Post 1.0 release we will go into feature freeze for core
> >>functionality
> >> to facilitate the JStorm merge.
> >> 4. During the feature freeze only fixes for high priority bugs in core
> >> functionality will be accepted (no new features).
> >> 5. During the feature freeze, enhancements to “external” modules can be
> >> accepted.
> >> 6. We will stop using the “beta” flag in favor of purely numeric version
> >> numbers. Stable vs. non-stable (development) releases can be indicated
> >>on
> >> the download page.
> >>
> >> Do we all agree?
> >>
> >> -Taylor
> >>
> >> > On Nov 11, 2015, at 4:10 PM, P. Taylor Goetz <pt...@gmail.com>
> >>wrote:
> >> >
> >> >
> >> >> On Nov 11, 2015, at 9:28 AM, Bobby Evans
> >><ev...@yahoo-inc.com.INVALID>
> >> wrote:
> >> >>
> >> >> I would like to see STORM-1190, STORM-1155, STORM-1198, STORM-1196,
> >> STORM-885, STORM-876, STORM-1145, STORM-831, and STORM-874 added to the
> >> list.
> >> >>
> >> >> Some of them are more important then others but they are all things I
> >> would like to see in a 0.11.0 release.
> >> >
> >> >
> >> > Cool. Thanks for listing them out. I will add them so they get
> >>tracked.
> >> >
> >> >
> >> >> On a side note I don't think the beta releases have been helpful. I
> >> would much rather just have a 0.11.0 go to 0.11.1 ... instead of
> >> 0.11.0-beta1, 0.11.0-beta2. To me the beta label is not that helpful,
> >>but
> >> it is not that big of a deal for me.
> >> >
> >> > In my mind, having releases tagged as “beta” were a way for us to say
> >>to
> >> users “here’s a preview release that will allow you to kick the tires on
> >> upcoming features, but be aware that there might be bugs. Let us know if
> >> you find any so we can fix them.”
> >> >
> >> > I think the intent was sound, but what I didn’t really see was user
> >> feedback on the beta releases, which is what I hoped would happen. So I
> >> have no problem with dropping the use of “beta” flags.
> >> >
> >> > Another approach I’ve seen other Apache projects use is to the
> >>numbering
> >> scheme you describe, and just have different labels/descriptions on the
> >> download page — i.e. “Latest stable release” and “Latest development
> >> release.” The nice part of that convention is that it does not have any
> >> impact on the release process. For example if we’re confident that a
> >> particular “development” release is actually quite stable, all we would
> >> have to do is update the downloads page, rather than go through the
> >>whole
> >> release/vote process just to remove the “beta” tag.
> >> >
> >> >> I also would like to see the 0.11 release tied to the plan for the
> >> JStorm merger. If we don't tie them together there can be code that
> >>does
> >> not make it into 0.11, but could make it into a 0.12 that will
> >>immediately
> >> be caught up in the merger, that could take a long time to complete. I
> >> mostly want us to be very transparent about what is likely to happen
> >>after
> >> 0.11 is released. So if someone has a feature that is close to getting
> >> something in to 0.11 that they speak up here instead of just deciding to
> >> wait for a 0.12 release.
> >> >
> >> >
> >> > I agree that the 0.11 release needs to be tied to the JStorm merger.
> >> Once that release goes out, we’ll be going into lockdown mode for the
> >>merge
> >> effort, which is likely to take a while.
> >> >
> >> > During that time it’s highly unlikely that any changes/additions to
> >> Storm’s core functionality will be accepted beyond high-priority bug
> >>fixes.
> >> Adding new features to the “external” components during that time is
> >> probably okay, since those components are sufficiently decoupled from
> >> Storm’s core functionality.
> >> >
> >> > So to reiterate Bobby’s statement:
> >> >
> >> > Please speak up now if there are any specific features or changes to
> >> Storm’s core functionality that you’d like to see in the next release.
> >> Otherwise you will have to wait.
> >> >
> >> >> - Bobby
> >> >
> >> > -Taylor
> >> >
> >> >>
> >> >>
> >> >> On Wednesday, November 11, 2015 6:32 AM, John Fang <
> >> xiaojian.fxj@alibaba-inc.com> wrote:
> >> >>
> >> >>
> >> >> Totally agree， it's great to accelerate the release speed. it is
> >> better release one official version within 3 months. The first month is
> >>for
> >> developing new features , .If some features hasn't been finished in this
> >> month, it will be put in the next release ticket. In the last two
> >>month, we
> >> just do test.
> >> >> Storm may face the greatest challenge in a big cluster, so I am more
> >> concerned about ZK Optimization as jstorm did. At last, it's great for
> >>the
> >> next release to has a test report about the stability and performance ,
> >>due
> >> to lots of new features in the latest versions.
> >> >>
> >> >> Regards
> >> >> John Fang
> >> >>
> >> >> -----邮件原件-----
> >> >> 发件人: P. Taylor Goetz [mailto:ptgoetz@gmail.com]
> >> >> 发送时间: 2015年11月11日 6:16
> >> >> 收件人: dev@storm.apache.org
> >> >> 主题: [DISCUSS] Initial 0.11.0 Release
> >> >>
> >> >> I’d like to start discussing our next release (0.11.0).
> >> >>
> >> >> First off, I’d like to create a list of issues/features that are
> >> in-progress and not yet merged to master, so we can start tracking them
> >>for
> >> inclusion in the release. If there are specific JIRAs you would like
> >> included, please reply, and I will add them to the wiki page for the
> >>0.11.0
> >> release [1].
> >> >>
> >> >> Second, I’d like to propose modifying the release cycle a bit. I’d
> >>like
> >> to continue the beta release cycle we started with 0.10.0, but this time
> >> I’d like to consider adding some sort of temporal constraint so we
> >>release
> >> new betas more often — something like a new beta release every 3 weeks
> >>or
> >> so until we feel confident in dropping the beta tag. IMHO, there was too
> >> long a gap between 0.10.0-beta1 and 0.10.0 and we should have had more
> >> interim releases during that time.
> >> >>
> >> >> Any thoughts?
> >> >>
> >> >> -Taylor
> >> >>
> >> >> [1]
> >>
> >>https://cwiki.apache.org/confluence/display/STORM/Release+0.11.0+Feature+
> >>Set
> >> >>
> >> >>
> >> >
> >>
> >>
> >
> >
> >--
> >Name : 임 정택
> >Blog : http://www.heartsavior.net / http://dev.heartsavior.net
> >Twitter : http://twitter.com/heartsavior
> >LinkedIn : http://www.linkedin.com/in/heartsavior
>
>
>
>
Re: [DISCUSS] 1.0 Release (was Re: [DISCUSS] Initial 0.11.0
Release)
Posted by Kyle Nusbaum <kn...@yahoo-inc.com.INVALID>.
I would prefer to wait until the JStorm code is merged to move to 1.0, and keep the current planned release as 0.11
My concern is that there will be significant functionality and possibly stability changes involved, and it feels more natural to have major changes be across a
major version release.
Rather than release 1.0 and then immediately make major changes to the project, I would propose we release 0.11, then do the freeze and merge the JStorm code, and the first release after that can be 1.0. -- Kyle
On Tuesday, November 17, 2015 1:57 PM, Bobby Evans <ev...@yahoo-inc.com.INVALID> wrote:
I have a pull request up now for these changes. I can run both new and old jars, but you have to use a new client when submitting an old jar or it will not work.
https://github.com/apache/storm/pull/889
- Bobby
On Tuesday, November 17, 2015 9:43 AM, Bobby Evans <ev...@yahoo-inc.com.INVALID> wrote:
I have a patch that is close, but like I said on the JIRA https://issues.apache.org/jira/browse/STORM-1202 we are not going to be able to make a storm-compat.jar work. Instead I have a binary that uses the shade code to rewrite the jar before it runs to match the new namespace. I am just doing some cleanup on the code and testing now before I put up the pull request either today or tomorrow. It too will be something that we can remove for a 2.0 release.
- Bobby
On Monday, November 16, 2015 7:23 PM, Harsha <st...@harsha.io> wrote:
+1 on Bobby's suggestion on moving the packages to storm-compat and have
it part of lib folder.
Moving 1.0 with org.apache.storm will make it easier in the future
rather than wait for 2.0 release we should make
this change now and in 2.0 we can remove the storm-compat jar.
Thanks,
Harsha
On Thu, Nov 12, 2015, at 07:15 AM, Bobby Evans wrote:
> I agree that having the old package names for a 1.0 release is a little
> odd, but I also am nervous about breaking backwards compatibility for our
> customers in a very significant way. The upgrade for us from 0.9.x to
> 0.10.x has gone fairly smoothly. Most customers read the announcement
> and recompiled their code against 0.10, but followed our instructions so
> that their topologies could run on both 0.9.x and 0.10.x. Having the
> ability for a topology to run on both an old cluster and a new cluster is
> very important for us, because of failover. If we want to minimize
> downtime we need to have the ability to fail a topology over from one
> cluster to another, usually running on the other side of the
> country/world. For stability reasons we do not want to upgrade both
> clusters at once, so we need to have confidence that a topology can run
> on both clusters. Maintaining two versions of a topology is a huge pain
> as well.
> Perhaps what we can do for 1.0 is to move all of the packages to
> org.apache.storm, but provide a storm-compat package that will still have
> the old user facing APIs in it, that are actually (for the most part)
> subclasses/interfaces of the org.apache versions. I am not sure this
> will work perfectly, but I think I will give it a try.
> - Bobby
>
>
> On Thursday, November 12, 2015 9:04 AM, Aaron. Dossett
> <Aa...@target.com> wrote:
>
>
> As a user/developer this sounds great. The only item that gives me
> pause
> is #2. Still seeing backtype.* package names would be unexpected (for
> me)
> for a 1.0 release. That small reservation aside, I am +1 (non-binding).
>
> On 11/11/15, 2:45 PM, "임정택" <ka...@gmail.com> wrote:
>
> >+1
> >
> >Jungtaek Lim (HeartSaVioR)
> >
> >2015-11-12 7:21 GMT+09:00 P. Taylor Goetz <pt...@gmail.com>:
> >
> >> Changing subject in order to consolidate discussion of a 1.0 release in
> >> one thread (there was some additional discussion in the thread regarding
> >> the JStorm code merge).
> >>
> >> I just want to make sure I’m accurately capturing the sentiment of the
> >> community with regard to a 1.0 release. Please correct me if my summary
> >> seems off-base or jump in with an opinion.
> >>
> >> In summary:
> >>
> >> 1. What we have been calling “0.11.0” will become the Storm 1.0 release.
> >> 2. We will NOT be migrating package names for this release (i.e.
> >> “backtype.storm” —> “org.apache.storm”).
> >> 3. Post 1.0 release we will go into feature freeze for core
> >>functionality
> >> to facilitate the JStorm merge.
> >> 4. During the feature freeze only fixes for high priority bugs in core
> >> functionality will be accepted (no new features).
> >> 5. During the feature freeze, enhancements to “external” modules can be
> >> accepted.
> >> 6. We will stop using the “beta” flag in favor of purely numeric version
> >> numbers. Stable vs. non-stable (development) releases can be indicated
> >>on
> >> the download page.
> >>
> >> Do we all agree?
> >>
> >> -Taylor
> >>
> >> > On Nov 11, 2015, at 4:10 PM, P. Taylor Goetz <pt...@gmail.com>
> >>wrote:
> >> >
> >> >
> >> >> On Nov 11, 2015, at 9:28 AM, Bobby Evans
> >><ev...@yahoo-inc.com.INVALID>
> >> wrote:
> >> >>
> >> >> I would like to see STORM-1190, STORM-1155, STORM-1198, STORM-1196,
> >> STORM-885, STORM-876, STORM-1145, STORM-831, and STORM-874 added to the
> >> list.
> >> >>
> >> >> Some of them are more important then others but they are all things I
> >> would like to see in a 0.11.0 release.
> >> >
> >> >
> >> > Cool. Thanks for listing them out. I will add them so they get
> >>tracked.
> >> >
> >> >
> >> >> On a side note I don't think the beta releases have been helpful. I
> >> would much rather just have a 0.11.0 go to 0.11.1 ... instead of
> >> 0.11.0-beta1, 0.11.0-beta2. To me the beta label is not that helpful,
> >>but
> >> it is not that big of a deal for me.
> >> >
> >> > In my mind, having releases tagged as “beta” were a way for us to say
> >>to
> >> users “here’s a preview release that will allow you to kick the tires on
> >> upcoming features, but be aware that there might be bugs. Let us know if
> >> you find any so we can fix them.”
> >> >
> >> > I think the intent was sound, but what I didn’t really see was user
> >> feedback on the beta releases, which is what I hoped would happen. So I
> >> have no problem with dropping the use of “beta” flags.
> >> >
> >> > Another approach I’ve seen other Apache projects use is to the
> >>numbering
> >> scheme you describe, and just have different labels/descriptions on the
> >> download page — i.e. “Latest stable release” and “Latest development
> >> release.” The nice part of that convention is that it does not have any
> >> impact on the release process. For example if we’re confident that a
> >> particular “development” release is actually quite stable, all we would
> >> have to do is update the downloads page, rather than go through the
> >>whole
> >> release/vote process just to remove the “beta” tag.
> >> >
> >> >> I also would like to see the 0.11 release tied to the plan for the
> >> JStorm merger. If we don't tie them together there can be code that
> >>does
> >> not make it into 0.11, but could make it into a 0.12 that will
> >>immediately
> >> be caught up in the merger, that could take a long time to complete. I
> >> mostly want us to be very transparent about what is likely to happen
> >>after
> >> 0.11 is released. So if someone has a feature that is close to getting
> >> something in to 0.11 that they speak up here instead of just deciding to
> >> wait for a 0.12 release.
> >> >
> >> >
> >> > I agree that the 0.11 release needs to be tied to the JStorm merger.
> >> Once that release goes out, we’ll be going into lockdown mode for the
> >>merge
> >> effort, which is likely to take a while.
> >> >
> >> > During that time it’s highly unlikely that any changes/additions to
> >> Storm’s core functionality will be accepted beyond high-priority bug
> >>fixes.
> >> Adding new features to the “external” components during that time is
> >> probably okay, since those components are sufficiently decoupled from
> >> Storm’s core functionality.
> >> >
> >> > So to reiterate Bobby’s statement:
> >> >
> >> > Please speak up now if there are any specific features or changes to
> >> Storm’s core functionality that you’d like to see in the next release.
> >> Otherwise you will have to wait.
> >> >
> >> >> - Bobby
> >> >
> >> > -Taylor
> >> >
> >> >>
> >> >>
> >> >> On Wednesday, November 11, 2015 6:32 AM, John Fang <
> >> xiaojian.fxj@alibaba-inc.com> wrote:
> >> >>
> >> >>
> >> >> Totally agree， it's great to accelerate the release speed. it is
> >> better release one official version within 3 months. The first month is
> >>for
> >> developing new features , .If some features hasn't been finished in this
> >> month, it will be put in the next release ticket. In the last two
> >>month, we
> >> just do test.
> >> >> Storm may face the greatest challenge in a big cluster, so I am more
> >> concerned about ZK Optimization as jstorm did. At last, it's great for
> >>the
> >> next release to has a test report about the stability and performance ,
> >>due
> >> to lots of new features in the latest versions.
> >> >>
> >> >> Regards
> >> >> John Fang
> >> >>
> >> >> -----邮件原件-----
> >> >> 发件人: P. Taylor Goetz [mailto:ptgoetz@gmail.com]
> >> >> 发送时间: 2015年11月11日 6:16
> >> >> 收件人: dev@storm.apache.org
> >> >> 主题: [DISCUSS] Initial 0.11.0 Release
> >> >>
> >> >> I’d like to start discussing our next release (0.11.0).
> >> >>
> >> >> First off, I’d like to create a list of issues/features that are
> >> in-progress and not yet merged to master, so we can start tracking them
> >>for
> >> inclusion in the release. If there are specific JIRAs you would like
> >> included, please reply, and I will add them to the wiki page for the
> >>0.11.0
> >> release [1].
> >> >>
> >> >> Second, I’d like to propose modifying the release cycle a bit. I’d
> >>like
> >> to continue the beta release cycle we started with 0.10.0, but this time
> >> I’d like to consider adding some sort of temporal constraint so we
> >>release
> >> new betas more often — something like a new beta release every 3 weeks
> >>or
> >> so until we feel confident in dropping the beta tag. IMHO, there was too
> >> long a gap between 0.10.0-beta1 and 0.10.0 and we should have had more
> >> interim releases during that time.
> >> >>
> >> >> Any thoughts?
> >> >>
> >> >> -Taylor
> >> >>
> >> >> [1]
> >>
> >>https://cwiki.apache.org/confluence/display/STORM/Release+0.11.0+Feature+
> >>Set
> >> >>
> >> >>
> >> >
> >>
> >>
> >
> >
> >--
> >Name : 임 정택
> >Blog : http://www.heartsavior.net / http://dev.heartsavior.net
> >Twitter : http://twitter.com/heartsavior
> >LinkedIn : http://www.linkedin.com/in/heartsavior
>
>
>
>
Re: [DISCUSS] 1.0 Release (was Re: [DISCUSS] Initial 0.11.0
Release)
Posted by Bobby Evans <ev...@yahoo-inc.com.INVALID>.
I have a pull request up now for these changes. I can run both new and old jars, but you have to use a new client when submitting an old jar or it will not work.
https://github.com/apache/storm/pull/889
- Bobby
On Tuesday, November 17, 2015 9:43 AM, Bobby Evans <ev...@yahoo-inc.com.INVALID> wrote:
I have a patch that is close, but like I said on the JIRA https://issues.apache.org/jira/browse/STORM-1202 we are not going to be able to make a storm-compat.jar work. Instead I have a binary that uses the shade code to rewrite the jar before it runs to match the new namespace. I am just doing some cleanup on the code and testing now before I put up the pull request either today or tomorrow. It too will be something that we can remove for a 2.0 release.
- Bobby
On Monday, November 16, 2015 7:23 PM, Harsha <st...@harsha.io> wrote:
+1 on Bobby's suggestion on moving the packages to storm-compat and have
it part of lib folder.
Moving 1.0 with org.apache.storm will make it easier in the future
rather than wait for 2.0 release we should make
this change now and in 2.0 we can remove the storm-compat jar.
Thanks,
Harsha
On Thu, Nov 12, 2015, at 07:15 AM, Bobby Evans wrote:
> I agree that having the old package names for a 1.0 release is a little
> odd, but I also am nervous about breaking backwards compatibility for our
> customers in a very significant way. The upgrade for us from 0.9.x to
> 0.10.x has gone fairly smoothly. Most customers read the announcement
> and recompiled their code against 0.10, but followed our instructions so
> that their topologies could run on both 0.9.x and 0.10.x. Having the
> ability for a topology to run on both an old cluster and a new cluster is
> very important for us, because of failover. If we want to minimize
> downtime we need to have the ability to fail a topology over from one
> cluster to another, usually running on the other side of the
> country/world. For stability reasons we do not want to upgrade both
> clusters at once, so we need to have confidence that a topology can run
> on both clusters. Maintaining two versions of a topology is a huge pain
> as well.
> Perhaps what we can do for 1.0 is to move all of the packages to
> org.apache.storm, but provide a storm-compat package that will still have
> the old user facing APIs in it, that are actually (for the most part)
> subclasses/interfaces of the org.apache versions. I am not sure this
> will work perfectly, but I think I will give it a try.
> - Bobby
>
>
> On Thursday, November 12, 2015 9:04 AM, Aaron. Dossett
> <Aa...@target.com> wrote:
>
>
> As a user/developer this sounds great. The only item that gives me
> pause
> is #2. Still seeing backtype.* package names would be unexpected (for
> me)
> for a 1.0 release. That small reservation aside, I am +1 (non-binding).
>
> On 11/11/15, 2:45 PM, "임정택" <ka...@gmail.com> wrote:
>
> >+1
> >
> >Jungtaek Lim (HeartSaVioR)
> >
> >2015-11-12 7:21 GMT+09:00 P. Taylor Goetz <pt...@gmail.com>:
> >
> >> Changing subject in order to consolidate discussion of a 1.0 release in
> >> one thread (there was some additional discussion in the thread regarding
> >> the JStorm code merge).
> >>
> >> I just want to make sure I’m accurately capturing the sentiment of the
> >> community with regard to a 1.0 release. Please correct me if my summary
> >> seems off-base or jump in with an opinion.
> >>
> >> In summary:
> >>
> >> 1. What we have been calling “0.11.0” will become the Storm 1.0 release.
> >> 2. We will NOT be migrating package names for this release (i.e.
> >> “backtype.storm” —> “org.apache.storm”).
> >> 3. Post 1.0 release we will go into feature freeze for core
> >>functionality
> >> to facilitate the JStorm merge.
> >> 4. During the feature freeze only fixes for high priority bugs in core
> >> functionality will be accepted (no new features).
> >> 5. During the feature freeze, enhancements to “external” modules can be
> >> accepted.
> >> 6. We will stop using the “beta” flag in favor of purely numeric version
> >> numbers. Stable vs. non-stable (development) releases can be indicated
> >>on
> >> the download page.
> >>
> >> Do we all agree?
> >>
> >> -Taylor
> >>
> >> > On Nov 11, 2015, at 4:10 PM, P. Taylor Goetz <pt...@gmail.com>
> >>wrote:
> >> >
> >> >
> >> >> On Nov 11, 2015, at 9:28 AM, Bobby Evans
> >><ev...@yahoo-inc.com.INVALID>
> >> wrote:
> >> >>
> >> >> I would like to see STORM-1190, STORM-1155, STORM-1198, STORM-1196,
> >> STORM-885, STORM-876, STORM-1145, STORM-831, and STORM-874 added to the
> >> list.
> >> >>
> >> >> Some of them are more important then others but they are all things I
> >> would like to see in a 0.11.0 release.
> >> >
> >> >
> >> > Cool. Thanks for listing them out. I will add them so they get
> >>tracked.
> >> >
> >> >
> >> >> On a side note I don't think the beta releases have been helpful. I
> >> would much rather just have a 0.11.0 go to 0.11.1 ... instead of
> >> 0.11.0-beta1, 0.11.0-beta2. To me the beta label is not that helpful,
> >>but
> >> it is not that big of a deal for me.
> >> >
> >> > In my mind, having releases tagged as “beta” were a way for us to say
> >>to
> >> users “here’s a preview release that will allow you to kick the tires on
> >> upcoming features, but be aware that there might be bugs. Let us know if
> >> you find any so we can fix them.”
> >> >
> >> > I think the intent was sound, but what I didn’t really see was user
> >> feedback on the beta releases, which is what I hoped would happen. So I
> >> have no problem with dropping the use of “beta” flags.
> >> >
> >> > Another approach I’ve seen other Apache projects use is to the
> >>numbering
> >> scheme you describe, and just have different labels/descriptions on the
> >> download page — i.e. “Latest stable release” and “Latest development
> >> release.” The nice part of that convention is that it does not have any
> >> impact on the release process. For example if we’re confident that a
> >> particular “development” release is actually quite stable, all we would
> >> have to do is update the downloads page, rather than go through the
> >>whole
> >> release/vote process just to remove the “beta” tag.
> >> >
> >> >> I also would like to see the 0.11 release tied to the plan for the
> >> JStorm merger. If we don't tie them together there can be code that
> >>does
> >> not make it into 0.11, but could make it into a 0.12 that will
> >>immediately
> >> be caught up in the merger, that could take a long time to complete. I
> >> mostly want us to be very transparent about what is likely to happen
> >>after
> >> 0.11 is released. So if someone has a feature that is close to getting
> >> something in to 0.11 that they speak up here instead of just deciding to
> >> wait for a 0.12 release.
> >> >
> >> >
> >> > I agree that the 0.11 release needs to be tied to the JStorm merger.
> >> Once that release goes out, we’ll be going into lockdown mode for the
> >>merge
> >> effort, which is likely to take a while.
> >> >
> >> > During that time it’s highly unlikely that any changes/additions to
> >> Storm’s core functionality will be accepted beyond high-priority bug
> >>fixes.
> >> Adding new features to the “external” components during that time is
> >> probably okay, since those components are sufficiently decoupled from
> >> Storm’s core functionality.
> >> >
> >> > So to reiterate Bobby’s statement:
> >> >
> >> > Please speak up now if there are any specific features or changes to
> >> Storm’s core functionality that you’d like to see in the next release.
> >> Otherwise you will have to wait.
> >> >
> >> >> - Bobby
> >> >
> >> > -Taylor
> >> >
> >> >>
> >> >>
> >> >> On Wednesday, November 11, 2015 6:32 AM, John Fang <
> >> xiaojian.fxj@alibaba-inc.com> wrote:
> >> >>
> >> >>
> >> >> Totally agree， it's great to accelerate the release speed. it is
> >> better release one official version within 3 months. The first month is
> >>for
> >> developing new features , .If some features hasn't been finished in this
> >> month, it will be put in the next release ticket. In the last two
> >>month, we
> >> just do test.
> >> >> Storm may face the greatest challenge in a big cluster, so I am more
> >> concerned about ZK Optimization as jstorm did. At last, it's great for
> >>the
> >> next release to has a test report about the stability and performance ,
> >>due
> >> to lots of new features in the latest versions.
> >> >>
> >> >> Regards
> >> >> John Fang
> >> >>
> >> >> -----邮件原件-----
> >> >> 发件人: P. Taylor Goetz [mailto:ptgoetz@gmail.com]
> >> >> 发送时间: 2015年11月11日 6:16
> >> >> 收件人: dev@storm.apache.org
> >> >> 主题: [DISCUSS] Initial 0.11.0 Release
> >> >>
> >> >> I’d like to start discussing our next release (0.11.0).
> >> >>
> >> >> First off, I’d like to create a list of issues/features that are
> >> in-progress and not yet merged to master, so we can start tracking them
> >>for
> >> inclusion in the release. If there are specific JIRAs you would like
> >> included, please reply, and I will add them to the wiki page for the
> >>0.11.0
> >> release [1].
> >> >>
> >> >> Second, I’d like to propose modifying the release cycle a bit. I’d
> >>like
> >> to continue the beta release cycle we started with 0.10.0, but this time
> >> I’d like to consider adding some sort of temporal constraint so we
> >>release
> >> new betas more often — something like a new beta release every 3 weeks
> >>or
> >> so until we feel confident in dropping the beta tag. IMHO, there was too
> >> long a gap between 0.10.0-beta1 and 0.10.0 and we should have had more
> >> interim releases during that time.
> >> >>
> >> >> Any thoughts?
> >> >>
> >> >> -Taylor
> >> >>
> >> >> [1]
> >>
> >>https://cwiki.apache.org/confluence/display/STORM/Release+0.11.0+Feature+
> >>Set
> >> >>
> >> >>
> >> >
> >>
> >>
> >
> >
> >--
> >Name : 임 정택
> >Blog : http://www.heartsavior.net / http://dev.heartsavior.net
> >Twitter : http://twitter.com/heartsavior
> >LinkedIn : http://www.linkedin.com/in/heartsavior
>
>
>
>
Re: [DISCUSS] 1.0 Release (was Re: [DISCUSS] Initial 0.11.0
Release)
Posted by Bobby Evans <ev...@yahoo-inc.com.INVALID>.
I have a patch that is close, but like I said on the JIRA https://issues.apache.org/jira/browse/STORM-1202 we are not going to be able to make a storm-compat.jar work. Instead I have a binary that uses the shade code to rewrite the jar before it runs to match the new namespace. I am just doing some cleanup on the code and testing now before I put up the pull request either today or tomorrow. It too will be something that we can remove for a 2.0 release.
- Bobby
On Monday, November 16, 2015 7:23 PM, Harsha <st...@harsha.io> wrote:
+1 on Bobby's suggestion on moving the packages to storm-compat and have
it part of lib folder.
Moving 1.0 with org.apache.storm will make it easier in the future
rather than wait for 2.0 release we should make
this change now and in 2.0 we can remove the storm-compat jar.
Thanks,
Harsha
On Thu, Nov 12, 2015, at 07:15 AM, Bobby Evans wrote:
> I agree that having the old package names for a 1.0 release is a little
> odd, but I also am nervous about breaking backwards compatibility for our
> customers in a very significant way. The upgrade for us from 0.9.x to
> 0.10.x has gone fairly smoothly. Most customers read the announcement
> and recompiled their code against 0.10, but followed our instructions so
> that their topologies could run on both 0.9.x and 0.10.x. Having the
> ability for a topology to run on both an old cluster and a new cluster is
> very important for us, because of failover. If we want to minimize
> downtime we need to have the ability to fail a topology over from one
> cluster to another, usually running on the other side of the
> country/world. For stability reasons we do not want to upgrade both
> clusters at once, so we need to have confidence that a topology can run
> on both clusters. Maintaining two versions of a topology is a huge pain
> as well.
> Perhaps what we can do for 1.0 is to move all of the packages to
> org.apache.storm, but provide a storm-compat package that will still have
> the old user facing APIs in it, that are actually (for the most part)
> subclasses/interfaces of the org.apache versions. I am not sure this
> will work perfectly, but I think I will give it a try.
> - Bobby
>
>
> On Thursday, November 12, 2015 9:04 AM, Aaron. Dossett
> <Aa...@target.com> wrote:
>
>
> As a user/developer this sounds great. The only item that gives me
> pause
> is #2. Still seeing backtype.* package names would be unexpected (for
> me)
> for a 1.0 release. That small reservation aside, I am +1 (non-binding).
>
> On 11/11/15, 2:45 PM, "임정택" <ka...@gmail.com> wrote:
>
> >+1
> >
> >Jungtaek Lim (HeartSaVioR)
> >
> >2015-11-12 7:21 GMT+09:00 P. Taylor Goetz <pt...@gmail.com>:
> >
> >> Changing subject in order to consolidate discussion of a 1.0 release in
> >> one thread (there was some additional discussion in the thread regarding
> >> the JStorm code merge).
> >>
> >> I just want to make sure I’m accurately capturing the sentiment of the
> >> community with regard to a 1.0 release. Please correct me if my summary
> >> seems off-base or jump in with an opinion.
> >>
> >> In summary:
> >>
> >> 1. What we have been calling “0.11.0” will become the Storm 1.0 release.
> >> 2. We will NOT be migrating package names for this release (i.e.
> >> “backtype.storm” —> “org.apache.storm”).
> >> 3. Post 1.0 release we will go into feature freeze for core
> >>functionality
> >> to facilitate the JStorm merge.
> >> 4. During the feature freeze only fixes for high priority bugs in core
> >> functionality will be accepted (no new features).
> >> 5. During the feature freeze, enhancements to “external” modules can be
> >> accepted.
> >> 6. We will stop using the “beta” flag in favor of purely numeric version
> >> numbers. Stable vs. non-stable (development) releases can be indicated
> >>on
> >> the download page.
> >>
> >> Do we all agree?
> >>
> >> -Taylor
> >>
> >> > On Nov 11, 2015, at 4:10 PM, P. Taylor Goetz <pt...@gmail.com>
> >>wrote:
> >> >
> >> >
> >> >> On Nov 11, 2015, at 9:28 AM, Bobby Evans
> >><ev...@yahoo-inc.com.INVALID>
> >> wrote:
> >> >>
> >> >> I would like to see STORM-1190, STORM-1155, STORM-1198, STORM-1196,
> >> STORM-885, STORM-876, STORM-1145, STORM-831, and STORM-874 added to the
> >> list.
> >> >>
> >> >> Some of them are more important then others but they are all things I
> >> would like to see in a 0.11.0 release.
> >> >
> >> >
> >> > Cool. Thanks for listing them out. I will add them so they get
> >>tracked.
> >> >
> >> >
> >> >> On a side note I don't think the beta releases have been helpful. I
> >> would much rather just have a 0.11.0 go to 0.11.1 ... instead of
> >> 0.11.0-beta1, 0.11.0-beta2. To me the beta label is not that helpful,
> >>but
> >> it is not that big of a deal for me.
> >> >
> >> > In my mind, having releases tagged as “beta” were a way for us to say
> >>to
> >> users “here’s a preview release that will allow you to kick the tires on
> >> upcoming features, but be aware that there might be bugs. Let us know if
> >> you find any so we can fix them.”
> >> >
> >> > I think the intent was sound, but what I didn’t really see was user
> >> feedback on the beta releases, which is what I hoped would happen. So I
> >> have no problem with dropping the use of “beta” flags.
> >> >
> >> > Another approach I’ve seen other Apache projects use is to the
> >>numbering
> >> scheme you describe, and just have different labels/descriptions on the
> >> download page — i.e. “Latest stable release” and “Latest development
> >> release.” The nice part of that convention is that it does not have any
> >> impact on the release process. For example if we’re confident that a
> >> particular “development” release is actually quite stable, all we would
> >> have to do is update the downloads page, rather than go through the
> >>whole
> >> release/vote process just to remove the “beta” tag.
> >> >
> >> >> I also would like to see the 0.11 release tied to the plan for the
> >> JStorm merger. If we don't tie them together there can be code that
> >>does
> >> not make it into 0.11, but could make it into a 0.12 that will
> >>immediately
> >> be caught up in the merger, that could take a long time to complete. I
> >> mostly want us to be very transparent about what is likely to happen
> >>after
> >> 0.11 is released. So if someone has a feature that is close to getting
> >> something in to 0.11 that they speak up here instead of just deciding to
> >> wait for a 0.12 release.
> >> >
> >> >
> >> > I agree that the 0.11 release needs to be tied to the JStorm merger.
> >> Once that release goes out, we’ll be going into lockdown mode for the
> >>merge
> >> effort, which is likely to take a while.
> >> >
> >> > During that time it’s highly unlikely that any changes/additions to
> >> Storm’s core functionality will be accepted beyond high-priority bug
> >>fixes.
> >> Adding new features to the “external” components during that time is
> >> probably okay, since those components are sufficiently decoupled from
> >> Storm’s core functionality.
> >> >
> >> > So to reiterate Bobby’s statement:
> >> >
> >> > Please speak up now if there are any specific features or changes to
> >> Storm’s core functionality that you’d like to see in the next release.
> >> Otherwise you will have to wait.
> >> >
> >> >> - Bobby
> >> >
> >> > -Taylor
> >> >
> >> >>
> >> >>
> >> >> On Wednesday, November 11, 2015 6:32 AM, John Fang <
> >> xiaojian.fxj@alibaba-inc.com> wrote:
> >> >>
> >> >>
> >> >> Totally agree， it's great to accelerate the release speed. it is
> >> better release one official version within 3 months. The first month is
> >>for
> >> developing new features , .If some features hasn't been finished in this
> >> month, it will be put in the next release ticket. In the last two
> >>month, we
> >> just do test.
> >> >> Storm may face the greatest challenge in a big cluster, so I am more
> >> concerned about ZK Optimization as jstorm did. At last, it's great for
> >>the
> >> next release to has a test report about the stability and performance ,
> >>due
> >> to lots of new features in the latest versions.
> >> >>
> >> >> Regards
> >> >> John Fang
> >> >>
> >> >> -----邮件原件-----
> >> >> 发件人: P. Taylor Goetz [mailto:ptgoetz@gmail.com]
> >> >> 发送时间: 2015年11月11日 6:16
> >> >> 收件人: dev@storm.apache.org
> >> >> 主题: [DISCUSS] Initial 0.11.0 Release
> >> >>
> >> >> I’d like to start discussing our next release (0.11.0).
> >> >>
> >> >> First off, I’d like to create a list of issues/features that are
> >> in-progress and not yet merged to master, so we can start tracking them
> >>for
> >> inclusion in the release. If there are specific JIRAs you would like
> >> included, please reply, and I will add them to the wiki page for the
> >>0.11.0
> >> release [1].
> >> >>
> >> >> Second, I’d like to propose modifying the release cycle a bit. I’d
> >>like
> >> to continue the beta release cycle we started with 0.10.0, but this time
> >> I’d like to consider adding some sort of temporal constraint so we
> >>release
> >> new betas more often — something like a new beta release every 3 weeks
> >>or
> >> so until we feel confident in dropping the beta tag. IMHO, there was too
> >> long a gap between 0.10.0-beta1 and 0.10.0 and we should have had more
> >> interim releases during that time.
> >> >>
> >> >> Any thoughts?
> >> >>
> >> >> -Taylor
> >> >>
> >> >> [1]
> >>
> >>https://cwiki.apache.org/confluence/display/STORM/Release+0.11.0+Feature+
> >>Set
> >> >>
> >> >>
> >> >
> >>
> >>
> >
> >
> >--
> >Name : 임 정택
> >Blog : http://www.heartsavior.net / http://dev.heartsavior.net
> >Twitter : http://twitter.com/heartsavior
> >LinkedIn : http://www.linkedin.com/in/heartsavior
>
>
>
>
Re: [DISCUSS] 1.0 Release (was Re: [DISCUSS] Initial 0.11.0 Release)
Posted by "封仲淹(纪君祥LongdaFeng)" <zh...@alibaba-inc.com>.
+1 as well.
(1) What we have been calling “0.11.0” will become the Storm 1.0 release.[Longda] Agree. we almost stop developing new feature after 0.11, so 0.11 is one big version of clojure core, I prefer we give it one big milestone number 1.0 to this version. In fact, this version will import some big featuer.
(2) switch from "backtype.storm" to "org.apache.storm"[Longda] Agree, but what I concern is three point: 2.1 is the storm-compat solution can resolve all package name problem. Has any other system used this technology before.2.2 The develop speed, I wish we can finish this feature as fast as we can. 2.3 This will lead to a little hard to trace all file's history. Because all file will be rename and modify.
RegardsLongda
------------------------------------------------------------------From:Hugo Da Cruz Louro <hl...@hortonworks.com>Send Time:2015年11月18日(星期三) 07:57To:dev@storm.apache.org <de...@storm.apache.org>Subject:Re: [DISCUSS] 1.0 Release (was Re: [DISCUSS] Initial 0.11.0 Release)
+1 as well. I support moving to the org.apache.storm package as early as possible and I am OK with storm-compat. My only concern with using storm-compat is if we are going to have to support it forever, or plan on dropping it after a certain release. Backwards compatibility is a valid concern but it can become very difficult to maintain older versions and at some point we must say that only topologies built after version X will run for version Y onwards (Y > X)
Hugo
> On Nov 16, 2015, at 5:23 PM, Harsha <st...@harsha.io> wrote:
>
> +1 on Bobby's suggestion on moving the packages to storm-compat and have
> it part of lib folder.
> Moving 1.0 with org.apache.storm will make it easier in the future
> rather than wait for 2.0 release we should make
> this change now and in 2.0 we can remove the storm-compat jar.
>
> Thanks,
> Harsha
>
>
> On Thu, Nov 12, 2015, at 07:15 AM, Bobby Evans wrote:
>> I agree that having the old package names for a 1.0 release is a little
>> odd, but I also am nervous about breaking backwards compatibility for our
>> customers in a very significant way. The upgrade for us from 0.9.x to
>> 0.10.x has gone fairly smoothly. Most customers read the announcement
>> and recompiled their code against 0.10, but followed our instructions so
>> that their topologies could run on both 0.9.x and 0.10.x. Having the
>> ability for a topology to run on both an old cluster and a new cluster is
>> very important for us, because of failover. If we want to minimize
>> downtime we need to have the ability to fail a topology over from one
>> cluster to another, usually running on the other side of the
>> country/world. For stability reasons we do not want to upgrade both
>> clusters at once, so we need to have confidence that a topology can run
>> on both clusters. Maintaining two versions of a topology is a huge pain
>> as well.
>> Perhaps what we can do for 1.0 is to move all of the packages to
>> org.apache.storm, but provide a storm-compat package that will still have
>> the old user facing APIs in it, that are actually (for the most part)
>> subclasses/interfaces of the org.apache versions. I am not sure this
>> will work perfectly, but I think I will give it a try.
>> - Bobby
>>
>>
>> On Thursday, November 12, 2015 9:04 AM, Aaron. Dossett
>> <Aa...@target.com> wrote:
>>
>>
>> As a user/developer this sounds great. The only item that gives me
>> pause
>> is #2. Still seeing backtype.* package names would be unexpected (for
>> me)
>> for a 1.0 release. That small reservation aside, I am +1 (non-binding).
>>
>> On 11/11/15, 2:45 PM, "임정택" <ka...@gmail.com> wrote:
>>
>>> +1
>>>
>>> Jungtaek Lim (HeartSaVioR)
>>>
>>> 2015-11-12 7:21 GMT+09:00 P. Taylor Goetz <pt...@gmail.com>:
>>>
>>>> Changing subject in order to consolidate discussion of a 1.0 release in
>>>> one thread (there was some additional discussion in the thread regarding
>>>> the JStorm code merge).
>>>>
>>>> I just want to make sure I’m accurately capturing the sentiment of the
>>>> community with regard to a 1.0 release. Please correct me if my summary
>>>> seems off-base or jump in with an opinion.
>>>>
>>>> In summary:
>>>>
>>>> 1. What we have been calling “0.11.0” will become the Storm 1.0 release.
>>>> 2. We will NOT be migrating package names for this release (i.e.
>>>> “backtype.storm” —> “org.apache.storm”).
>>>> 3. Post 1.0 release we will go into feature freeze for core
>>>> functionality
>>>> to facilitate the JStorm merge.
>>>> 4. During the feature freeze only fixes for high priority bugs in core
>>>> functionality will be accepted (no new features).
>>>> 5. During the feature freeze, enhancements to “external” modules can be
>>>> accepted.
>>>> 6. We will stop using the “beta” flag in favor of purely numeric version
>>>> numbers. Stable vs. non-stable (development) releases can be indicated
>>>> on
>>>> the download page.
>>>>
>>>> Do we all agree?
>>>>
>>>> -Taylor
>>>>
>>>>> On Nov 11, 2015, at 4:10 PM, P. Taylor Goetz <pt...@gmail.com>
>>>> wrote:
>>>>>
>>>>>
>>>>>> On Nov 11, 2015, at 9:28 AM, Bobby Evans
>>>> <ev...@yahoo-inc.com.INVALID>
>>>> wrote:
>>>>>>
>>>>>> I would like to see STORM-1190, STORM-1155, STORM-1198, STORM-1196,
>>>> STORM-885, STORM-876, STORM-1145, STORM-831, and STORM-874 added to the
>>>> list.
>>>>>>
>>>>>> Some of them are more important then others but they are all things I
>>>> would like to see in a 0.11.0 release.
>>>>>
>>>>>
>>>>> Cool. Thanks for listing them out. I will add them so they get
>>>> tracked.
>>>>>
>>>>>
>>>>>> On a side note I don't think the beta releases have been helpful. I
>>>> would much rather just have a 0.11.0 go to 0.11.1 ... instead of
>>>> 0.11.0-beta1, 0.11.0-beta2. To me the beta label is not that helpful,
>>>> but
>>>> it is not that big of a deal for me.
>>>>>
>>>>> In my mind, having releases tagged as “beta” were a way for us to say
>>>> to
>>>> users “here’s a preview release that will allow you to kick the tires on
>>>> upcoming features, but be aware that there might be bugs. Let us know if
>>>> you find any so we can fix them.”
>>>>>
>>>>> I think the intent was sound, but what I didn’t really see was user
>>>> feedback on the beta releases, which is what I hoped would happen. So I
>>>> have no problem with dropping the use of “beta” flags.
>>>>>
>>>>> Another approach I’ve seen other Apache projects use is to the
>>>> numbering
>>>> scheme you describe, and just have different labels/descriptions on the
>>>> download page — i.e. “Latest stable release” and “Latest development
>>>> release.” The nice part of that convention is that it does not have any
>>>> impact on the release process. For example if we’re confident that a
>>>> particular “development” release is actually quite stable, all we would
>>>> have to do is update the downloads page, rather than go through the
>>>> whole
>>>> release/vote process just to remove the “beta” tag.
>>>>>
>>>>>> I also would like to see the 0.11 release tied to the plan for the
>>>> JStorm merger. If we don't tie them together there can be code that
>>>> does
>>>> not make it into 0.11, but could make it into a 0.12 that will
>>>> immediately
>>>> be caught up in the merger, that could take a long time to complete. I
>>>> mostly want us to be very transparent about what is likely to happen
>>>> after
>>>> 0.11 is released. So if someone has a feature that is close to getting
>>>> something in to 0.11 that they speak up here instead of just deciding to
>>>> wait for a 0.12 release.
>>>>>
>>>>>
>>>>> I agree that the 0.11 release needs to be tied to the JStorm merger.
>>>> Once that release goes out, we’ll be going into lockdown mode for the
>>>> merge
>>>> effort, which is likely to take a while.
>>>>>
>>>>> During that time it’s highly unlikely that any changes/additions to
>>>> Storm’s core functionality will be accepted beyond high-priority bug
>>>> fixes.
>>>> Adding new features to the “external” components during that time is
>>>> probably okay, since those components are sufficiently decoupled from
>>>> Storm’s core functionality.
>>>>>
>>>>> So to reiterate Bobby’s statement:
>>>>>
>>>>> Please speak up now if there are any specific features or changes to
>>>> Storm’s core functionality that you’d like to see in the next release.
>>>> Otherwise you will have to wait.
>>>>>
>>>>>> - Bobby
>>>>>
>>>>> -Taylor
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wednesday, November 11, 2015 6:32 AM, John Fang <
>>>> xiaojian.fxj@alibaba-inc.com> wrote:
>>>>>>
>>>>>>
>>>>>> Totally agree， it's great to accelerate the release speed. it is
>>>> better release one official version within 3 months. The first month is
>>>> for
>>>> developing new features , .If some features hasn't been finished in this
>>>> month, it will be put in the next release ticket. In the last two
>>>> month, we
>>>> just do test.
>>>>>> Storm may face the greatest challenge in a big cluster, so I am more
>>>> concerned about ZK Optimization as jstorm did. At last, it's great for
>>>> the
>>>> next release to has a test report about the stability and performance ,
>>>> due
>>>> to lots of new features in the latest versions.
>>>>>>
>>>>>> Regards
>>>>>> John Fang
>>>>>>
>>>>>> -----邮件原件-----
>>>>>> 发件人: P. Taylor Goetz [mailto:ptgoetz@gmail.com]
>>>>>> 发送时间: 2015年11月11日 6:16
>>>>>> 收件人: dev@storm.apache.org
>>>>>> 主题: [DISCUSS] Initial 0.11.0 Release
>>>>>>
>>>>>> I’d like to start discussing our next release (0.11.0).
>>>>>>
>>>>>> First off, I’d like to create a list of issues/features that are
>>>> in-progress and not yet merged to master, so we can start tracking them
>>>> for
>>>> inclusion in the release. If there are specific JIRAs you would like
>>>> included, please reply, and I will add them to the wiki page for the
>>>> 0.11.0
>>>> release [1].
>>>>>>
>>>>>> Second, I’d like to propose modifying the release cycle a bit. I’d
>>>> like
>>>> to continue the beta release cycle we started with 0.10.0, but this time
>>>> I’d like to consider adding some sort of temporal constraint so we
>>>> release
>>>> new betas more often — something like a new beta release every 3 weeks
>>>> or
>>>> so until we feel confident in dropping the beta tag. IMHO, there was too
>>>> long a gap between 0.10.0-beta1 and 0.10.0 and we should have had more
>>>> interim releases during that time.
>>>>>>
>>>>>> Any thoughts?
>>>>>>
>>>>>> -Taylor
>>>>>>
>>>>>> [1]
>>>>
>>>> https://cwiki.apache.org/confluence/display/STORM/Release+0.11.0+Feature+
>>>> Set
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Name : 임 정택
>>> Blog : http://www.heartsavior.net / http://dev.heartsavior.net
>>> Twitter : http://twitter.com/heartsavior
>>> LinkedIn : http://www.linkedin.com/in/heartsavior
>>
>>
>>
>>
>
Re: [DISCUSS] 1.0 Release (was Re: [DISCUSS] Initial 0.11.0
Release)
Posted by Bobby Evans <ev...@yahoo-inc.com.INVALID>.
My concern for backwards compatibility is really to provide a clean upgrade path to my users. So for me it is mostly maintaining some form of backwards compatibility for a few months until all the users have upgraded. This is because we have multiple clusters and having users maintain two versions of their code so they can run on multiple clusters is something they would complain a lot about. I know that for other groups it will likely be similar, but their time-frame and the versions they will be going from/to will be different. In general I am in favor of maintaining API, wire, and binary compatibility as long as is easily possible, and if we cannot it needs to be a conscious decision that involves changing the major version number of storm. Changing the package names is very much a non-backwards compatible change. But in this case the backwards compatibility I put in is a real hack. That is why I put it in a jar named storm-rename-hack in a java package named org.apache.storm.hack. Additionally it is off by default, and when it is on, and it does anything to the jar it warns you repeatedly that you need to upgrade your namespaces. I personally think that this is a one off situation. We are not going to break compatibility that often, because we have the tools we need to maintain compatibility, and we have been using them fairly well lately. Now that being said compatibility is theoretical until someone actually tests it. Small bugs can always creep in so if you do want to go from one version to another you need to be sure that you have tested it, like any other software.
- Bobby
On Tuesday, November 17, 2015 5:57 PM, Hugo Da Cruz Louro <hl...@hortonworks.com> wrote:
+1 as well. I support moving to the org.apache.storm package as early as possible and I am OK with storm-compat. My only concern with using storm-compat is if we are going to have to support it forever, or plan on dropping it after a certain release. Backwards compatibility is a valid concern but it can become very difficult to maintain older versions and at some point we must say that only topologies built after version X will run for version Y onwards (Y > X)
Hugo
> On Nov 16, 2015, at 5:23 PM, Harsha <st...@harsha.io> wrote:
>
> +1 on Bobby's suggestion on moving the packages to storm-compat and have
> it part of lib folder.
> Moving 1.0 with org.apache.storm will make it easier in the future
> rather than wait for 2.0 release we should make
> this change now and in 2.0 we can remove the storm-compat jar.
>
> Thanks,
> Harsha
>
>
> On Thu, Nov 12, 2015, at 07:15 AM, Bobby Evans wrote:
>> I agree that having the old package names for a 1.0 release is a little
>> odd, but I also am nervous about breaking backwards compatibility for our
>> customers in a very significant way. The upgrade for us from 0.9.x to
>> 0.10.x has gone fairly smoothly. Most customers read the announcement
>> and recompiled their code against 0.10, but followed our instructions so
>> that their topologies could run on both 0.9.x and 0.10.x. Having the
>> ability for a topology to run on both an old cluster and a new cluster is
>> very important for us, because of failover. If we want to minimize
>> downtime we need to have the ability to fail a topology over from one
>> cluster to another, usually running on the other side of the
>> country/world. For stability reasons we do not want to upgrade both
>> clusters at once, so we need to have confidence that a topology can run
>> on both clusters. Maintaining two versions of a topology is a huge pain
>> as well.
>> Perhaps what we can do for 1.0 is to move all of the packages to
>> org.apache.storm, but provide a storm-compat package that will still have
>> the old user facing APIs in it, that are actually (for the most part)
>> subclasses/interfaces of the org.apache versions. I am not sure this
>> will work perfectly, but I think I will give it a try.
>> - Bobby
>>
>>
>> On Thursday, November 12, 2015 9:04 AM, Aaron. Dossett
>> <Aa...@target.com> wrote:
>>
>>
>> As a user/developer this sounds great. The only item that gives me
>> pause
>> is #2. Still seeing backtype.* package names would be unexpected (for
>> me)
>> for a 1.0 release. That small reservation aside, I am +1 (non-binding).
>>
>> On 11/11/15, 2:45 PM, "임정택" <ka...@gmail.com> wrote:
>>
>>> +1
>>>
>>> Jungtaek Lim (HeartSaVioR)
>>>
>>> 2015-11-12 7:21 GMT+09:00 P. Taylor Goetz <pt...@gmail.com>:
>>>
>>>> Changing subject in order to consolidate discussion of a 1.0 release in
>>>> one thread (there was some additional discussion in the thread regarding
>>>> the JStorm code merge).
>>>>
>>>> I just want to make sure I’m accurately capturing the sentiment of the
>>>> community with regard to a 1.0 release. Please correct me if my summary
>>>> seems off-base or jump in with an opinion.
>>>>
>>>> In summary:
>>>>
>>>> 1. What we have been calling “0.11.0” will become the Storm 1.0 release.
>>>> 2. We will NOT be migrating package names for this release (i.e.
>>>> “backtype.storm” —> “org.apache.storm”).
>>>> 3. Post 1.0 release we will go into feature freeze for core
>>>> functionality
>>>> to facilitate the JStorm merge.
>>>> 4. During the feature freeze only fixes for high priority bugs in core
>>>> functionality will be accepted (no new features).
>>>> 5. During the feature freeze, enhancements to “external” modules can be
>>>> accepted.
>>>> 6. We will stop using the “beta” flag in favor of purely numeric version
>>>> numbers. Stable vs. non-stable (development) releases can be indicated
>>>> on
>>>> the download page.
>>>>
>>>> Do we all agree?
>>>>
>>>> -Taylor
>>>>
>>>>> On Nov 11, 2015, at 4:10 PM, P. Taylor Goetz <pt...@gmail.com>
>>>> wrote:
>>>>>
>>>>>
>>>>>> On Nov 11, 2015, at 9:28 AM, Bobby Evans
>>>> <ev...@yahoo-inc.com.INVALID>
>>>> wrote:
>>>>>>
>>>>>> I would like to see STORM-1190, STORM-1155, STORM-1198, STORM-1196,
>>>> STORM-885, STORM-876, STORM-1145, STORM-831, and STORM-874 added to the
>>>> list.
>>>>>>
>>>>>> Some of them are more important then others but they are all things I
>>>> would like to see in a 0.11.0 release.
>>>>>
>>>>>
>>>>> Cool. Thanks for listing them out. I will add them so they get
>>>> tracked.
>>>>>
>>>>>
>>>>>> On a side note I don't think the beta releases have been helpful. I
>>>> would much rather just have a 0.11.0 go to 0.11.1 ... instead of
>>>> 0.11.0-beta1, 0.11.0-beta2. To me the beta label is not that helpful,
>>>> but
>>>> it is not that big of a deal for me.
>>>>>
>>>>> In my mind, having releases tagged as “beta” were a way for us to say
>>>> to
>>>> users “here’s a preview release that will allow you to kick the tires on
>>>> upcoming features, but be aware that there might be bugs. Let us know if
>>>> you find any so we can fix them.”
>>>>>
>>>>> I think the intent was sound, but what I didn’t really see was user
>>>> feedback on the beta releases, which is what I hoped would happen. So I
>>>> have no problem with dropping the use of “beta” flags.
>>>>>
>>>>> Another approach I’ve seen other Apache projects use is to the
>>>> numbering
>>>> scheme you describe, and just have different labels/descriptions on the
>>>> download page — i.e. “Latest stable release” and “Latest development
>>>> release.” The nice part of that convention is that it does not have any
>>>> impact on the release process. For example if we’re confident that a
>>>> particular “development” release is actually quite stable, all we would
>>>> have to do is update the downloads page, rather than go through the
>>>> whole
>>>> release/vote process just to remove the “beta” tag.
>>>>>
>>>>>> I also would like to see the 0.11 release tied to the plan for the
>>>> JStorm merger. If we don't tie them together there can be code that
>>>> does
>>>> not make it into 0.11, but could make it into a 0.12 that will
>>>> immediately
>>>> be caught up in the merger, that could take a long time to complete. I
>>>> mostly want us to be very transparent about what is likely to happen
>>>> after
>>>> 0.11 is released. So if someone has a feature that is close to getting
>>>> something in to 0.11 that they speak up here instead of just deciding to
>>>> wait for a 0.12 release.
>>>>>
>>>>>
>>>>> I agree that the 0.11 release needs to be tied to the JStorm merger.
>>>> Once that release goes out, we’ll be going into lockdown mode for the
>>>> merge
>>>> effort, which is likely to take a while.
>>>>>
>>>>> During that time it’s highly unlikely that any changes/additions to
>>>> Storm’s core functionality will be accepted beyond high-priority bug
>>>> fixes.
>>>> Adding new features to the “external” components during that time is
>>>> probably okay, since those components are sufficiently decoupled from
>>>> Storm’s core functionality.
>>>>>
>>>>> So to reiterate Bobby’s statement:
>>>>>
>>>>> Please speak up now if there are any specific features or changes to
>>>> Storm’s core functionality that you’d like to see in the next release.
>>>> Otherwise you will have to wait.
>>>>>
>>>>>> - Bobby
>>>>>
>>>>> -Taylor
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wednesday, November 11, 2015 6:32 AM, John Fang <
>>>> xiaojian.fxj@alibaba-inc.com> wrote:
>>>>>>
>>>>>>
>>>>>> Totally agree， it's great to accelerate the release speed. it is
>>>> better release one official version within 3 months. The first month is
>>>> for
>>>> developing new features , .If some features hasn't been finished in this
>>>> month, it will be put in the next release ticket. In the last two
>>>> month, we
>>>> just do test.
>>>>>> Storm may face the greatest challenge in a big cluster, so I am more
>>>> concerned about ZK Optimization as jstorm did. At last, it's great for
>>>> the
>>>> next release to has a test report about the stability and performance ,
>>>> due
>>>> to lots of new features in the latest versions.
>>>>>>
>>>>>> Regards
>>>>>> John Fang
>>>>>>
>>>>>> -----邮件原件-----
>>>>>> 发件人: P. Taylor Goetz [mailto:ptgoetz@gmail.com]
>>>>>> 发送时间: 2015年11月11日 6:16
>>>>>> 收件人: dev@storm.apache.org
>>>>>> 主题: [DISCUSS] Initial 0.11.0 Release
>>>>>>
>>>>>> I’d like to start discussing our next release (0.11.0).
>>>>>>
>>>>>> First off, I’d like to create a list of issues/features that are
>>>> in-progress and not yet merged to master, so we can start tracking them
>>>> for
>>>> inclusion in the release. If there are specific JIRAs you would like
>>>> included, please reply, and I will add them to the wiki page for the
>>>> 0.11.0
>>>> release [1].
>>>>>>
>>>>>> Second, I’d like to propose modifying the release cycle a bit. I’d
>>>> like
>>>> to continue the beta release cycle we started with 0.10.0, but this time
>>>> I’d like to consider adding some sort of temporal constraint so we
>>>> release
>>>> new betas more often — something like a new beta release every 3 weeks
>>>> or
>>>> so until we feel confident in dropping the beta tag. IMHO, there was too
>>>> long a gap between 0.10.0-beta1 and 0.10.0 and we should have had more
>>>> interim releases during that time.
>>>>>>
>>>>>> Any thoughts?
>>>>>>
>>>>>> -Taylor
>>>>>>
>>>>>> [1]
>>>>
>>>> https://cwiki.apache.org/confluence/display/STORM/Release+0.11.0+Feature+
>>>> Set
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Name : 임 정택
>>> Blog : http://www.heartsavior.net / http://dev.heartsavior.net
>>> Twitter : http://twitter.com/heartsavior
>>> LinkedIn : http://www.linkedin.com/in/heartsavior
>>
>>
>>
>>
>
Re: [DISCUSS] 1.0 Release (was Re: [DISCUSS] Initial 0.11.0
Release)
Posted by Hugo Da Cruz Louro <hl...@hortonworks.com>.
+1 as well. I support moving to the org.apache.storm package as early as possible and I am OK with storm-compat. My only concern with using storm-compat is if we are going to have to support it forever, or plan on dropping it after a certain release. Backwards compatibility is a valid concern but it can become very difficult to maintain older versions and at some point we must say that only topologies built after version X will run for version Y onwards (Y > X)
Hugo
> On Nov 16, 2015, at 5:23 PM, Harsha <st...@harsha.io> wrote:
>
> +1 on Bobby's suggestion on moving the packages to storm-compat and have
> it part of lib folder.
> Moving 1.0 with org.apache.storm will make it easier in the future
> rather than wait for 2.0 release we should make
> this change now and in 2.0 we can remove the storm-compat jar.
>
> Thanks,
> Harsha
>
>
> On Thu, Nov 12, 2015, at 07:15 AM, Bobby Evans wrote:
>> I agree that having the old package names for a 1.0 release is a little
>> odd, but I also am nervous about breaking backwards compatibility for our
>> customers in a very significant way. The upgrade for us from 0.9.x to
>> 0.10.x has gone fairly smoothly. Most customers read the announcement
>> and recompiled their code against 0.10, but followed our instructions so
>> that their topologies could run on both 0.9.x and 0.10.x. Having the
>> ability for a topology to run on both an old cluster and a new cluster is
>> very important for us, because of failover. If we want to minimize
>> downtime we need to have the ability to fail a topology over from one
>> cluster to another, usually running on the other side of the
>> country/world. For stability reasons we do not want to upgrade both
>> clusters at once, so we need to have confidence that a topology can run
>> on both clusters. Maintaining two versions of a topology is a huge pain
>> as well.
>> Perhaps what we can do for 1.0 is to move all of the packages to
>> org.apache.storm, but provide a storm-compat package that will still have
>> the old user facing APIs in it, that are actually (for the most part)
>> subclasses/interfaces of the org.apache versions. I am not sure this
>> will work perfectly, but I think I will give it a try.
>> - Bobby
>>
>>
>> On Thursday, November 12, 2015 9:04 AM, Aaron. Dossett
>> <Aa...@target.com> wrote:
>>
>>
>> As a user/developer this sounds great. The only item that gives me
>> pause
>> is #2. Still seeing backtype.* package names would be unexpected (for
>> me)
>> for a 1.0 release. That small reservation aside, I am +1 (non-binding).
>>
>> On 11/11/15, 2:45 PM, "임정택" <ka...@gmail.com> wrote:
>>
>>> +1
>>>
>>> Jungtaek Lim (HeartSaVioR)
>>>
>>> 2015-11-12 7:21 GMT+09:00 P. Taylor Goetz <pt...@gmail.com>:
>>>
>>>> Changing subject in order to consolidate discussion of a 1.0 release in
>>>> one thread (there was some additional discussion in the thread regarding
>>>> the JStorm code merge).
>>>>
>>>> I just want to make sure I’m accurately capturing the sentiment of the
>>>> community with regard to a 1.0 release. Please correct me if my summary
>>>> seems off-base or jump in with an opinion.
>>>>
>>>> In summary:
>>>>
>>>> 1. What we have been calling “0.11.0” will become the Storm 1.0 release.
>>>> 2. We will NOT be migrating package names for this release (i.e.
>>>> “backtype.storm” —> “org.apache.storm”).
>>>> 3. Post 1.0 release we will go into feature freeze for core
>>>> functionality
>>>> to facilitate the JStorm merge.
>>>> 4. During the feature freeze only fixes for high priority bugs in core
>>>> functionality will be accepted (no new features).
>>>> 5. During the feature freeze, enhancements to “external” modules can be
>>>> accepted.
>>>> 6. We will stop using the “beta” flag in favor of purely numeric version
>>>> numbers. Stable vs. non-stable (development) releases can be indicated
>>>> on
>>>> the download page.
>>>>
>>>> Do we all agree?
>>>>
>>>> -Taylor
>>>>
>>>>> On Nov 11, 2015, at 4:10 PM, P. Taylor Goetz <pt...@gmail.com>
>>>> wrote:
>>>>>
>>>>>
>>>>>> On Nov 11, 2015, at 9:28 AM, Bobby Evans
>>>> <ev...@yahoo-inc.com.INVALID>
>>>> wrote:
>>>>>>
>>>>>> I would like to see STORM-1190, STORM-1155, STORM-1198, STORM-1196,
>>>> STORM-885, STORM-876, STORM-1145, STORM-831, and STORM-874 added to the
>>>> list.
>>>>>>
>>>>>> Some of them are more important then others but they are all things I
>>>> would like to see in a 0.11.0 release.
>>>>>
>>>>>
>>>>> Cool. Thanks for listing them out. I will add them so they get
>>>> tracked.
>>>>>
>>>>>
>>>>>> On a side note I don't think the beta releases have been helpful. I
>>>> would much rather just have a 0.11.0 go to 0.11.1 ... instead of
>>>> 0.11.0-beta1, 0.11.0-beta2. To me the beta label is not that helpful,
>>>> but
>>>> it is not that big of a deal for me.
>>>>>
>>>>> In my mind, having releases tagged as “beta” were a way for us to say
>>>> to
>>>> users “here’s a preview release that will allow you to kick the tires on
>>>> upcoming features, but be aware that there might be bugs. Let us know if
>>>> you find any so we can fix them.”
>>>>>
>>>>> I think the intent was sound, but what I didn’t really see was user
>>>> feedback on the beta releases, which is what I hoped would happen. So I
>>>> have no problem with dropping the use of “beta” flags.
>>>>>
>>>>> Another approach I’ve seen other Apache projects use is to the
>>>> numbering
>>>> scheme you describe, and just have different labels/descriptions on the
>>>> download page — i.e. “Latest stable release” and “Latest development
>>>> release.” The nice part of that convention is that it does not have any
>>>> impact on the release process. For example if we’re confident that a
>>>> particular “development” release is actually quite stable, all we would
>>>> have to do is update the downloads page, rather than go through the
>>>> whole
>>>> release/vote process just to remove the “beta” tag.
>>>>>
>>>>>> I also would like to see the 0.11 release tied to the plan for the
>>>> JStorm merger. If we don't tie them together there can be code that
>>>> does
>>>> not make it into 0.11, but could make it into a 0.12 that will
>>>> immediately
>>>> be caught up in the merger, that could take a long time to complete. I
>>>> mostly want us to be very transparent about what is likely to happen
>>>> after
>>>> 0.11 is released. So if someone has a feature that is close to getting
>>>> something in to 0.11 that they speak up here instead of just deciding to
>>>> wait for a 0.12 release.
>>>>>
>>>>>
>>>>> I agree that the 0.11 release needs to be tied to the JStorm merger.
>>>> Once that release goes out, we’ll be going into lockdown mode for the
>>>> merge
>>>> effort, which is likely to take a while.
>>>>>
>>>>> During that time it’s highly unlikely that any changes/additions to
>>>> Storm’s core functionality will be accepted beyond high-priority bug
>>>> fixes.
>>>> Adding new features to the “external” components during that time is
>>>> probably okay, since those components are sufficiently decoupled from
>>>> Storm’s core functionality.
>>>>>
>>>>> So to reiterate Bobby’s statement:
>>>>>
>>>>> Please speak up now if there are any specific features or changes to
>>>> Storm’s core functionality that you’d like to see in the next release.
>>>> Otherwise you will have to wait.
>>>>>
>>>>>> - Bobby
>>>>>
>>>>> -Taylor
>>>>>
>>>>>>
>>>>>>
>>>>>> On Wednesday, November 11, 2015 6:32 AM, John Fang <
>>>> xiaojian.fxj@alibaba-inc.com> wrote:
>>>>>>
>>>>>>
>>>>>> Totally agree， it's great to accelerate the release speed. it is
>>>> better release one official version within 3 months. The first month is
>>>> for
>>>> developing new features , .If some features hasn't been finished in this
>>>> month, it will be put in the next release ticket. In the last two
>>>> month, we
>>>> just do test.
>>>>>> Storm may face the greatest challenge in a big cluster, so I am more
>>>> concerned about ZK Optimization as jstorm did. At last, it's great for
>>>> the
>>>> next release to has a test report about the stability and performance ,
>>>> due
>>>> to lots of new features in the latest versions.
>>>>>>
>>>>>> Regards
>>>>>> John Fang
>>>>>>
>>>>>> -----邮件原件-----
>>>>>> 发件人: P. Taylor Goetz [mailto:ptgoetz@gmail.com]
>>>>>> 发送时间: 2015年11月11日 6:16
>>>>>> 收件人: dev@storm.apache.org
>>>>>> 主题: [DISCUSS] Initial 0.11.0 Release
>>>>>>
>>>>>> I’d like to start discussing our next release (0.11.0).
>>>>>>
>>>>>> First off, I’d like to create a list of issues/features that are
>>>> in-progress and not yet merged to master, so we can start tracking them
>>>> for
>>>> inclusion in the release. If there are specific JIRAs you would like
>>>> included, please reply, and I will add them to the wiki page for the
>>>> 0.11.0
>>>> release [1].
>>>>>>
>>>>>> Second, I’d like to propose modifying the release cycle a bit. I’d
>>>> like
>>>> to continue the beta release cycle we started with 0.10.0, but this time
>>>> I’d like to consider adding some sort of temporal constraint so we
>>>> release
>>>> new betas more often — something like a new beta release every 3 weeks
>>>> or
>>>> so until we feel confident in dropping the beta tag. IMHO, there was too
>>>> long a gap between 0.10.0-beta1 and 0.10.0 and we should have had more
>>>> interim releases during that time.
>>>>>>
>>>>>> Any thoughts?
>>>>>>
>>>>>> -Taylor
>>>>>>
>>>>>> [1]
>>>>
>>>> https://cwiki.apache.org/confluence/display/STORM/Release+0.11.0+Feature+
>>>> Set
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Name : 임 정택
>>> Blog : http://www.heartsavior.net / http://dev.heartsavior.net
>>> Twitter : http://twitter.com/heartsavior
>>> LinkedIn : http://www.linkedin.com/in/heartsavior
>>
>>
>>
>>
>
Re: [DISCUSS] 1.0 Release (was Re: [DISCUSS] Initial 0.11.0 Release)
Posted by Harsha <st...@harsha.io>.
+1 on Bobby's suggestion on moving the packages to storm-compat and have
it part of lib folder.
Moving 1.0 with org.apache.storm will make it easier in the future
rather than wait for 2.0 release we should make
this change now and in 2.0 we can remove the storm-compat jar.
Thanks,
Harsha
On Thu, Nov 12, 2015, at 07:15 AM, Bobby Evans wrote:
> I agree that having the old package names for a 1.0 release is a little
> odd, but I also am nervous about breaking backwards compatibility for our
> customers in a very significant way. The upgrade for us from 0.9.x to
> 0.10.x has gone fairly smoothly. Most customers read the announcement
> and recompiled their code against 0.10, but followed our instructions so
> that their topologies could run on both 0.9.x and 0.10.x. Having the
> ability for a topology to run on both an old cluster and a new cluster is
> very important for us, because of failover. If we want to minimize
> downtime we need to have the ability to fail a topology over from one
> cluster to another, usually running on the other side of the
> country/world. For stability reasons we do not want to upgrade both
> clusters at once, so we need to have confidence that a topology can run
> on both clusters. Maintaining two versions of a topology is a huge pain
> as well.
> Perhaps what we can do for 1.0 is to move all of the packages to
> org.apache.storm, but provide a storm-compat package that will still have
> the old user facing APIs in it, that are actually (for the most part)
> subclasses/interfaces of the org.apache versions. I am not sure this
> will work perfectly, but I think I will give it a try.
> - Bobby
>
>
> On Thursday, November 12, 2015 9:04 AM, Aaron. Dossett
> <Aa...@target.com> wrote:
>
>
> As a user/developer this sounds great. The only item that gives me
> pause
> is #2. Still seeing backtype.* package names would be unexpected (for
> me)
> for a 1.0 release. That small reservation aside, I am +1 (non-binding).
>
> On 11/11/15, 2:45 PM, "임정택" <ka...@gmail.com> wrote:
>
> >+1
> >
> >Jungtaek Lim (HeartSaVioR)
> >
> >2015-11-12 7:21 GMT+09:00 P. Taylor Goetz <pt...@gmail.com>:
> >
> >> Changing subject in order to consolidate discussion of a 1.0 release in
> >> one thread (there was some additional discussion in the thread regarding
> >> the JStorm code merge).
> >>
> >> I just want to make sure I’m accurately capturing the sentiment of the
> >> community with regard to a 1.0 release. Please correct me if my summary
> >> seems off-base or jump in with an opinion.
> >>
> >> In summary:
> >>
> >> 1. What we have been calling “0.11.0” will become the Storm 1.0 release.
> >> 2. We will NOT be migrating package names for this release (i.e.
> >> “backtype.storm” —> “org.apache.storm”).
> >> 3. Post 1.0 release we will go into feature freeze for core
> >>functionality
> >> to facilitate the JStorm merge.
> >> 4. During the feature freeze only fixes for high priority bugs in core
> >> functionality will be accepted (no new features).
> >> 5. During the feature freeze, enhancements to “external” modules can be
> >> accepted.
> >> 6. We will stop using the “beta” flag in favor of purely numeric version
> >> numbers. Stable vs. non-stable (development) releases can be indicated
> >>on
> >> the download page.
> >>
> >> Do we all agree?
> >>
> >> -Taylor
> >>
> >> > On Nov 11, 2015, at 4:10 PM, P. Taylor Goetz <pt...@gmail.com>
> >>wrote:
> >> >
> >> >
> >> >> On Nov 11, 2015, at 9:28 AM, Bobby Evans
> >><ev...@yahoo-inc.com.INVALID>
> >> wrote:
> >> >>
> >> >> I would like to see STORM-1190, STORM-1155, STORM-1198, STORM-1196,
> >> STORM-885, STORM-876, STORM-1145, STORM-831, and STORM-874 added to the
> >> list.
> >> >>
> >> >> Some of them are more important then others but they are all things I
> >> would like to see in a 0.11.0 release.
> >> >
> >> >
> >> > Cool. Thanks for listing them out. I will add them so they get
> >>tracked.
> >> >
> >> >
> >> >> On a side note I don't think the beta releases have been helpful. I
> >> would much rather just have a 0.11.0 go to 0.11.1 ... instead of
> >> 0.11.0-beta1, 0.11.0-beta2. To me the beta label is not that helpful,
> >>but
> >> it is not that big of a deal for me.
> >> >
> >> > In my mind, having releases tagged as “beta” were a way for us to say
> >>to
> >> users “here’s a preview release that will allow you to kick the tires on
> >> upcoming features, but be aware that there might be bugs. Let us know if
> >> you find any so we can fix them.”
> >> >
> >> > I think the intent was sound, but what I didn’t really see was user
> >> feedback on the beta releases, which is what I hoped would happen. So I
> >> have no problem with dropping the use of “beta” flags.
> >> >
> >> > Another approach I’ve seen other Apache projects use is to the
> >>numbering
> >> scheme you describe, and just have different labels/descriptions on the
> >> download page — i.e. “Latest stable release” and “Latest development
> >> release.” The nice part of that convention is that it does not have any
> >> impact on the release process. For example if we’re confident that a
> >> particular “development” release is actually quite stable, all we would
> >> have to do is update the downloads page, rather than go through the
> >>whole
> >> release/vote process just to remove the “beta” tag.
> >> >
> >> >> I also would like to see the 0.11 release tied to the plan for the
> >> JStorm merger. If we don't tie them together there can be code that
> >>does
> >> not make it into 0.11, but could make it into a 0.12 that will
> >>immediately
> >> be caught up in the merger, that could take a long time to complete. I
> >> mostly want us to be very transparent about what is likely to happen
> >>after
> >> 0.11 is released. So if someone has a feature that is close to getting
> >> something in to 0.11 that they speak up here instead of just deciding to
> >> wait for a 0.12 release.
> >> >
> >> >
> >> > I agree that the 0.11 release needs to be tied to the JStorm merger.
> >> Once that release goes out, we’ll be going into lockdown mode for the
> >>merge
> >> effort, which is likely to take a while.
> >> >
> >> > During that time it’s highly unlikely that any changes/additions to
> >> Storm’s core functionality will be accepted beyond high-priority bug
> >>fixes.
> >> Adding new features to the “external” components during that time is
> >> probably okay, since those components are sufficiently decoupled from
> >> Storm’s core functionality.
> >> >
> >> > So to reiterate Bobby’s statement:
> >> >
> >> > Please speak up now if there are any specific features or changes to
> >> Storm’s core functionality that you’d like to see in the next release.
> >> Otherwise you will have to wait.
> >> >
> >> >> - Bobby
> >> >
> >> > -Taylor
> >> >
> >> >>
> >> >>
> >> >> On Wednesday, November 11, 2015 6:32 AM, John Fang <
> >> xiaojian.fxj@alibaba-inc.com> wrote:
> >> >>
> >> >>
> >> >> Totally agree， it's great to accelerate the release speed. it is
> >> better release one official version within 3 months. The first month is
> >>for
> >> developing new features , .If some features hasn't been finished in this
> >> month, it will be put in the next release ticket. In the last two
> >>month, we
> >> just do test.
> >> >> Storm may face the greatest challenge in a big cluster, so I am more
> >> concerned about ZK Optimization as jstorm did. At last, it's great for
> >>the
> >> next release to has a test report about the stability and performance ,
> >>due
> >> to lots of new features in the latest versions.
> >> >>
> >> >> Regards
> >> >> John Fang
> >> >>
> >> >> -----邮件原件-----
> >> >> 发件人: P. Taylor Goetz [mailto:ptgoetz@gmail.com]
> >> >> 发送时间: 2015年11月11日 6:16
> >> >> 收件人: dev@storm.apache.org
> >> >> 主题: [DISCUSS] Initial 0.11.0 Release
> >> >>
> >> >> I’d like to start discussing our next release (0.11.0).
> >> >>
> >> >> First off, I’d like to create a list of issues/features that are
> >> in-progress and not yet merged to master, so we can start tracking them
> >>for
> >> inclusion in the release. If there are specific JIRAs you would like
> >> included, please reply, and I will add them to the wiki page for the
> >>0.11.0
> >> release [1].
> >> >>
> >> >> Second, I’d like to propose modifying the release cycle a bit. I’d
> >>like
> >> to continue the beta release cycle we started with 0.10.0, but this time
> >> I’d like to consider adding some sort of temporal constraint so we
> >>release
> >> new betas more often — something like a new beta release every 3 weeks
> >>or
> >> so until we feel confident in dropping the beta tag. IMHO, there was too
> >> long a gap between 0.10.0-beta1 and 0.10.0 and we should have had more
> >> interim releases during that time.
> >> >>
> >> >> Any thoughts?
> >> >>
> >> >> -Taylor
> >> >>
> >> >> [1]
> >>
> >>https://cwiki.apache.org/confluence/display/STORM/Release+0.11.0+Feature+
> >>Set
> >> >>
> >> >>
> >> >
> >>
> >>
> >
> >
> >--
> >Name : 임 정택
> >Blog : http://www.heartsavior.net / http://dev.heartsavior.net
> >Twitter : http://twitter.com/heartsavior
> >LinkedIn : http://www.linkedin.com/in/heartsavior
>
>
>
>
Re: [DISCUSS] 1.0 Release (was Re: [DISCUSS] Initial 0.11.0
Release)
Posted by Bobby Evans <ev...@yahoo-inc.com.INVALID>.
I agree that having the old package names for a 1.0 release is a little odd, but I also am nervous about breaking backwards compatibility for our customers in a very significant way. The upgrade for us from 0.9.x to 0.10.x has gone fairly smoothly. Most customers read the announcement and recompiled their code against 0.10, but followed our instructions so that their topologies could run on both 0.9.x and 0.10.x. Having the ability for a topology to run on both an old cluster and a new cluster is very important for us, because of failover. If we want to minimize downtime we need to have the ability to fail a topology over from one cluster to another, usually running on the other side of the country/world. For stability reasons we do not want to upgrade both clusters at once, so we need to have confidence that a topology can run on both clusters. Maintaining two versions of a topology is a huge pain as well.
Perhaps what we can do for 1.0 is to move all of the packages to org.apache.storm, but provide a storm-compat package that will still have the old user facing APIs in it, that are actually (for the most part) subclasses/interfaces of the org.apache versions. I am not sure this will work perfectly, but I think I will give it a try.
- Bobby
On Thursday, November 12, 2015 9:04 AM, Aaron. Dossett <Aa...@target.com> wrote:
As a user/developer this sounds great. The only item that gives me pause
is #2. Still seeing backtype.* package names would be unexpected (for me)
for a 1.0 release. That small reservation aside, I am +1 (non-binding).
On 11/11/15, 2:45 PM, "임정택" <ka...@gmail.com> wrote:
>+1
>
>Jungtaek Lim (HeartSaVioR)
>
>2015-11-12 7:21 GMT+09:00 P. Taylor Goetz <pt...@gmail.com>:
>
>> Changing subject in order to consolidate discussion of a 1.0 release in
>> one thread (there was some additional discussion in the thread regarding
>> the JStorm code merge).
>>
>> I just want to make sure I’m accurately capturing the sentiment of the
>> community with regard to a 1.0 release. Please correct me if my summary
>> seems off-base or jump in with an opinion.
>>
>> In summary:
>>
>> 1. What we have been calling “0.11.0” will become the Storm 1.0 release.
>> 2. We will NOT be migrating package names for this release (i.e.
>> “backtype.storm” —> “org.apache.storm”).
>> 3. Post 1.0 release we will go into feature freeze for core
>>functionality
>> to facilitate the JStorm merge.
>> 4. During the feature freeze only fixes for high priority bugs in core
>> functionality will be accepted (no new features).
>> 5. During the feature freeze, enhancements to “external” modules can be
>> accepted.
>> 6. We will stop using the “beta” flag in favor of purely numeric version
>> numbers. Stable vs. non-stable (development) releases can be indicated
>>on
>> the download page.
>>
>> Do we all agree?
>>
>> -Taylor
>>
>> > On Nov 11, 2015, at 4:10 PM, P. Taylor Goetz <pt...@gmail.com>
>>wrote:
>> >
>> >
>> >> On Nov 11, 2015, at 9:28 AM, Bobby Evans
>><ev...@yahoo-inc.com.INVALID>
>> wrote:
>> >>
>> >> I would like to see STORM-1190, STORM-1155, STORM-1198, STORM-1196,
>> STORM-885, STORM-876, STORM-1145, STORM-831, and STORM-874 added to the
>> list.
>> >>
>> >> Some of them are more important then others but they are all things I
>> would like to see in a 0.11.0 release.
>> >
>> >
>> > Cool. Thanks for listing them out. I will add them so they get
>>tracked.
>> >
>> >
>> >> On a side note I don't think the beta releases have been helpful. I
>> would much rather just have a 0.11.0 go to 0.11.1 ... instead of
>> 0.11.0-beta1, 0.11.0-beta2. To me the beta label is not that helpful,
>>but
>> it is not that big of a deal for me.
>> >
>> > In my mind, having releases tagged as “beta” were a way for us to say
>>to
>> users “here’s a preview release that will allow you to kick the tires on
>> upcoming features, but be aware that there might be bugs. Let us know if
>> you find any so we can fix them.”
>> >
>> > I think the intent was sound, but what I didn’t really see was user
>> feedback on the beta releases, which is what I hoped would happen. So I
>> have no problem with dropping the use of “beta” flags.
>> >
>> > Another approach I’ve seen other Apache projects use is to the
>>numbering
>> scheme you describe, and just have different labels/descriptions on the
>> download page — i.e. “Latest stable release” and “Latest development
>> release.” The nice part of that convention is that it does not have any
>> impact on the release process. For example if we’re confident that a
>> particular “development” release is actually quite stable, all we would
>> have to do is update the downloads page, rather than go through the
>>whole
>> release/vote process just to remove the “beta” tag.
>> >
>> >> I also would like to see the 0.11 release tied to the plan for the
>> JStorm merger. If we don't tie them together there can be code that
>>does
>> not make it into 0.11, but could make it into a 0.12 that will
>>immediately
>> be caught up in the merger, that could take a long time to complete. I
>> mostly want us to be very transparent about what is likely to happen
>>after
>> 0.11 is released. So if someone has a feature that is close to getting
>> something in to 0.11 that they speak up here instead of just deciding to
>> wait for a 0.12 release.
>> >
>> >
>> > I agree that the 0.11 release needs to be tied to the JStorm merger.
>> Once that release goes out, we’ll be going into lockdown mode for the
>>merge
>> effort, which is likely to take a while.
>> >
>> > During that time it’s highly unlikely that any changes/additions to
>> Storm’s core functionality will be accepted beyond high-priority bug
>>fixes.
>> Adding new features to the “external” components during that time is
>> probably okay, since those components are sufficiently decoupled from
>> Storm’s core functionality.
>> >
>> > So to reiterate Bobby’s statement:
>> >
>> > Please speak up now if there are any specific features or changes to
>> Storm’s core functionality that you’d like to see in the next release.
>> Otherwise you will have to wait.
>> >
>> >> - Bobby
>> >
>> > -Taylor
>> >
>> >>
>> >>
>> >> On Wednesday, November 11, 2015 6:32 AM, John Fang <
>> xiaojian.fxj@alibaba-inc.com> wrote:
>> >>
>> >>
>> >> Totally agree， it's great to accelerate the release speed. it is
>> better release one official version within 3 months. The first month is
>>for
>> developing new features , .If some features hasn't been finished in this
>> month, it will be put in the next release ticket. In the last two
>>month, we
>> just do test.
>> >> Storm may face the greatest challenge in a big cluster, so I am more
>> concerned about ZK Optimization as jstorm did. At last, it's great for
>>the
>> next release to has a test report about the stability and performance ,
>>due
>> to lots of new features in the latest versions.
>> >>
>> >> Regards
>> >> John Fang
>> >>
>> >> -----邮件原件-----
>> >> 发件人: P. Taylor Goetz [mailto:ptgoetz@gmail.com]
>> >> 发送时间: 2015年11月11日 6:16
>> >> 收件人: dev@storm.apache.org
>> >> 主题: [DISCUSS] Initial 0.11.0 Release
>> >>
>> >> I’d like to start discussing our next release (0.11.0).
>> >>
>> >> First off, I’d like to create a list of issues/features that are
>> in-progress and not yet merged to master, so we can start tracking them
>>for
>> inclusion in the release. If there are specific JIRAs you would like
>> included, please reply, and I will add them to the wiki page for the
>>0.11.0
>> release [1].
>> >>
>> >> Second, I’d like to propose modifying the release cycle a bit. I’d
>>like
>> to continue the beta release cycle we started with 0.10.0, but this time
>> I’d like to consider adding some sort of temporal constraint so we
>>release
>> new betas more often — something like a new beta release every 3 weeks
>>or
>> so until we feel confident in dropping the beta tag. IMHO, there was too
>> long a gap between 0.10.0-beta1 and 0.10.0 and we should have had more
>> interim releases during that time.
>> >>
>> >> Any thoughts?
>> >>
>> >> -Taylor
>> >>
>> >> [1]
>>
>>https://cwiki.apache.org/confluence/display/STORM/Release+0.11.0+Feature+
>>Set
>> >>
>> >>
>> >
>>
>>
>
>
>--
>Name : 임 정택
>Blog : http://www.heartsavior.net / http://dev.heartsavior.net
>Twitter : http://twitter.com/heartsavior
>LinkedIn : http://www.linkedin.com/in/heartsavior
Re: [DISCUSS] 1.0 Release (was Re: [DISCUSS] Initial 0.11.0 Release)
Posted by "Aaron.Dossett" <Aa...@target.com>.
As a user/developer this sounds great. The only item that gives me pause
is #2. Still seeing backtype.* package names would be unexpected (for me)
for a 1.0 release. That small reservation aside, I am +1 (non-binding).
On 11/11/15, 2:45 PM, "임정택" <ka...@gmail.com> wrote:
>+1
>
>Jungtaek Lim (HeartSaVioR)
>
>2015-11-12 7:21 GMT+09:00 P. Taylor Goetz <pt...@gmail.com>:
>
>> Changing subject in order to consolidate discussion of a 1.0 release in
>> one thread (there was some additional discussion in the thread regarding
>> the JStorm code merge).
>>
>> I just want to make sure I’m accurately capturing the sentiment of the
>> community with regard to a 1.0 release. Please correct me if my summary
>> seems off-base or jump in with an opinion.
>>
>> In summary:
>>
>> 1. What we have been calling “0.11.0” will become the Storm 1.0 release.
>> 2. We will NOT be migrating package names for this release (i.e.
>> “backtype.storm” —> “org.apache.storm”).
>> 3. Post 1.0 release we will go into feature freeze for core
>>functionality
>> to facilitate the JStorm merge.
>> 4. During the feature freeze only fixes for high priority bugs in core
>> functionality will be accepted (no new features).
>> 5. During the feature freeze, enhancements to “external” modules can be
>> accepted.
>> 6. We will stop using the “beta” flag in favor of purely numeric version
>> numbers. Stable vs. non-stable (development) releases can be indicated
>>on
>> the download page.
>>
>> Do we all agree?
>>
>> -Taylor
>>
>> > On Nov 11, 2015, at 4:10 PM, P. Taylor Goetz <pt...@gmail.com>
>>wrote:
>> >
>> >
>> >> On Nov 11, 2015, at 9:28 AM, Bobby Evans
>><ev...@yahoo-inc.com.INVALID>
>> wrote:
>> >>
>> >> I would like to see STORM-1190, STORM-1155, STORM-1198, STORM-1196,
>> STORM-885, STORM-876, STORM-1145, STORM-831, and STORM-874 added to the
>> list.
>> >>
>> >> Some of them are more important then others but they are all things I
>> would like to see in a 0.11.0 release.
>> >
>> >
>> > Cool. Thanks for listing them out. I will add them so they get
>>tracked.
>> >
>> >
>> >> On a side note I don't think the beta releases have been helpful. I
>> would much rather just have a 0.11.0 go to 0.11.1 ... instead of
>> 0.11.0-beta1, 0.11.0-beta2. To me the beta label is not that helpful,
>>but
>> it is not that big of a deal for me.
>> >
>> > In my mind, having releases tagged as “beta” were a way for us to say
>>to
>> users “here’s a preview release that will allow you to kick the tires on
>> upcoming features, but be aware that there might be bugs. Let us know if
>> you find any so we can fix them.”
>> >
>> > I think the intent was sound, but what I didn’t really see was user
>> feedback on the beta releases, which is what I hoped would happen. So I
>> have no problem with dropping the use of “beta” flags.
>> >
>> > Another approach I’ve seen other Apache projects use is to the
>>numbering
>> scheme you describe, and just have different labels/descriptions on the
>> download page — i.e. “Latest stable release” and “Latest development
>> release.” The nice part of that convention is that it does not have any
>> impact on the release process. For example if we’re confident that a
>> particular “development” release is actually quite stable, all we would
>> have to do is update the downloads page, rather than go through the
>>whole
>> release/vote process just to remove the “beta” tag.
>> >
>> >> I also would like to see the 0.11 release tied to the plan for the
>> JStorm merger. If we don't tie them together there can be code that
>>does
>> not make it into 0.11, but could make it into a 0.12 that will
>>immediately
>> be caught up in the merger, that could take a long time to complete. I
>> mostly want us to be very transparent about what is likely to happen
>>after
>> 0.11 is released. So if someone has a feature that is close to getting
>> something in to 0.11 that they speak up here instead of just deciding to
>> wait for a 0.12 release.
>> >
>> >
>> > I agree that the 0.11 release needs to be tied to the JStorm merger.
>> Once that release goes out, we’ll be going into lockdown mode for the
>>merge
>> effort, which is likely to take a while.
>> >
>> > During that time it’s highly unlikely that any changes/additions to
>> Storm’s core functionality will be accepted beyond high-priority bug
>>fixes.
>> Adding new features to the “external” components during that time is
>> probably okay, since those components are sufficiently decoupled from
>> Storm’s core functionality.
>> >
>> > So to reiterate Bobby’s statement:
>> >
>> > Please speak up now if there are any specific features or changes to
>> Storm’s core functionality that you’d like to see in the next release.
>> Otherwise you will have to wait.
>> >
>> >> - Bobby
>> >
>> > -Taylor
>> >
>> >>
>> >>
>> >> On Wednesday, November 11, 2015 6:32 AM, John Fang <
>> xiaojian.fxj@alibaba-inc.com> wrote:
>> >>
>> >>
>> >> Totally agree， it's great to accelerate the release speed. it is
>> better release one official version within 3 months. The first month is
>>for
>> developing new features , .If some features hasn't been finished in this
>> month, it will be put in the next release ticket. In the last two
>>month, we
>> just do test.
>> >> Storm may face the greatest challenge in a big cluster, so I am more
>> concerned about ZK Optimization as jstorm did. At last, it's great for
>>the
>> next release to has a test report about the stability and performance ,
>>due
>> to lots of new features in the latest versions.
>> >>
>> >> Regards
>> >> John Fang
>> >>
>> >> -----邮件原件-----
>> >> 发件人: P. Taylor Goetz [mailto:ptgoetz@gmail.com]
>> >> 发送时间: 2015年11月11日 6:16
>> >> 收件人: dev@storm.apache.org
>> >> 主题: [DISCUSS] Initial 0.11.0 Release
>> >>
>> >> I’d like to start discussing our next release (0.11.0).
>> >>
>> >> First off, I’d like to create a list of issues/features that are
>> in-progress and not yet merged to master, so we can start tracking them
>>for
>> inclusion in the release. If there are specific JIRAs you would like
>> included, please reply, and I will add them to the wiki page for the
>>0.11.0
>> release [1].
>> >>
>> >> Second, I’d like to propose modifying the release cycle a bit. I’d
>>like
>> to continue the beta release cycle we started with 0.10.0, but this time
>> I’d like to consider adding some sort of temporal constraint so we
>>release
>> new betas more often — something like a new beta release every 3 weeks
>>or
>> so until we feel confident in dropping the beta tag. IMHO, there was too
>> long a gap between 0.10.0-beta1 and 0.10.0 and we should have had more
>> interim releases during that time.
>> >>
>> >> Any thoughts?
>> >>
>> >> -Taylor
>> >>
>> >> [1]
>>
>>https://cwiki.apache.org/confluence/display/STORM/Release+0.11.0+Feature+
>>Set
>> >>
>> >>
>> >
>>
>>
>
>
>--
>Name : 임 정택
>Blog : http://www.heartsavior.net / http://dev.heartsavior.net
>Twitter : http://twitter.com/heartsavior
>LinkedIn : http://www.linkedin.com/in/heartsavior
Re: [DISCUSS] 1.0 Release (was Re: [DISCUSS] Initial 0.11.0 Release)
Posted by 임정택 <ka...@gmail.com>.
+1
Jungtaek Lim (HeartSaVioR)
2015-11-12 7:21 GMT+09:00 P. Taylor Goetz <pt...@gmail.com>:
> Changing subject in order to consolidate discussion of a 1.0 release in
> one thread (there was some additional discussion in the thread regarding
> the JStorm code merge).
>
> I just want to make sure I’m accurately capturing the sentiment of the
> community with regard to a 1.0 release. Please correct me if my summary
> seems off-base or jump in with an opinion.
>
> In summary:
>
> 1. What we have been calling “0.11.0” will become the Storm 1.0 release.
> 2. We will NOT be migrating package names for this release (i.e.
> “backtype.storm” —> “org.apache.storm”).
> 3. Post 1.0 release we will go into feature freeze for core functionality
> to facilitate the JStorm merge.
> 4. During the feature freeze only fixes for high priority bugs in core
> functionality will be accepted (no new features).
> 5. During the feature freeze, enhancements to “external” modules can be
> accepted.
> 6. We will stop using the “beta” flag in favor of purely numeric version
> numbers. Stable vs. non-stable (development) releases can be indicated on
> the download page.
>
> Do we all agree?
>
> -Taylor
>
> > On Nov 11, 2015, at 4:10 PM, P. Taylor Goetz <pt...@gmail.com> wrote:
> >
> >
> >> On Nov 11, 2015, at 9:28 AM, Bobby Evans <ev...@yahoo-inc.com.INVALID>
> wrote:
> >>
> >> I would like to see STORM-1190, STORM-1155, STORM-1198, STORM-1196,
> STORM-885, STORM-876, STORM-1145, STORM-831, and STORM-874 added to the
> list.
> >>
> >> Some of them are more important then others but they are all things I
> would like to see in a 0.11.0 release.
> >
> >
> > Cool. Thanks for listing them out. I will add them so they get tracked.
> >
> >
> >> On a side note I don't think the beta releases have been helpful. I
> would much rather just have a 0.11.0 go to 0.11.1 ... instead of
> 0.11.0-beta1, 0.11.0-beta2. To me the beta label is not that helpful, but
> it is not that big of a deal for me.
> >
> > In my mind, having releases tagged as “beta” were a way for us to say to
> users “here’s a preview release that will allow you to kick the tires on
> upcoming features, but be aware that there might be bugs. Let us know if
> you find any so we can fix them.”
> >
> > I think the intent was sound, but what I didn’t really see was user
> feedback on the beta releases, which is what I hoped would happen. So I
> have no problem with dropping the use of “beta” flags.
> >
> > Another approach I’ve seen other Apache projects use is to the numbering
> scheme you describe, and just have different labels/descriptions on the
> download page — i.e. “Latest stable release” and “Latest development
> release.” The nice part of that convention is that it does not have any
> impact on the release process. For example if we’re confident that a
> particular “development” release is actually quite stable, all we would
> have to do is update the downloads page, rather than go through the whole
> release/vote process just to remove the “beta” tag.
> >
> >> I also would like to see the 0.11 release tied to the plan for the
> JStorm merger. If we don't tie them together there can be code that does
> not make it into 0.11, but could make it into a 0.12 that will immediately
> be caught up in the merger, that could take a long time to complete. I
> mostly want us to be very transparent about what is likely to happen after
> 0.11 is released. So if someone has a feature that is close to getting
> something in to 0.11 that they speak up here instead of just deciding to
> wait for a 0.12 release.
> >
> >
> > I agree that the 0.11 release needs to be tied to the JStorm merger.
> Once that release goes out, we’ll be going into lockdown mode for the merge
> effort, which is likely to take a while.
> >
> > During that time it’s highly unlikely that any changes/additions to
> Storm’s core functionality will be accepted beyond high-priority bug fixes.
> Adding new features to the “external” components during that time is
> probably okay, since those components are sufficiently decoupled from
> Storm’s core functionality.
> >
> > So to reiterate Bobby’s statement:
> >
> > Please speak up now if there are any specific features or changes to
> Storm’s core functionality that you’d like to see in the next release.
> Otherwise you will have to wait.
> >
> >> - Bobby
> >
> > -Taylor
> >
> >>
> >>
> >> On Wednesday, November 11, 2015 6:32 AM, John Fang <
> xiaojian.fxj@alibaba-inc.com> wrote:
> >>
> >>
> >> Totally agree， it's great to accelerate the release speed. it is
> better release one official version within 3 months. The first month is for
> developing new features , .If some features hasn't been finished in this
> month, it will be put in the next release ticket. In the last two month, we
> just do test.
> >> Storm may face the greatest challenge in a big cluster, so I am more
> concerned about ZK Optimization as jstorm did. At last, it's great for the
> next release to has a test report about the stability and performance , due
> to lots of new features in the latest versions.
> >>
> >> Regards
> >> John Fang
> >>
> >> -----邮件原件-----
> >> 发件人: P. Taylor Goetz [mailto:ptgoetz@gmail.com]
> >> 发送时间: 2015年11月11日 6:16
> >> 收件人: dev@storm.apache.org
> >> 主题: [DISCUSS] Initial 0.11.0 Release
> >>
> >> I’d like to start discussing our next release (0.11.0).
> >>
> >> First off, I’d like to create a list of issues/features that are
> in-progress and not yet merged to master, so we can start tracking them for
> inclusion in the release. If there are specific JIRAs you would like
> included, please reply, and I will add them to the wiki page for the 0.11.0
> release [1].
> >>
> >> Second, I’d like to propose modifying the release cycle a bit. I’d like
> to continue the beta release cycle we started with 0.10.0, but this time
> I’d like to consider adding some sort of temporal constraint so we release
> new betas more often — something like a new beta release every 3 weeks or
> so until we feel confident in dropping the beta tag. IMHO, there was too
> long a gap between 0.10.0-beta1 and 0.10.0 and we should have had more
> interim releases during that time.
> >>
> >> Any thoughts?
> >>
> >> -Taylor
> >>
> >> [1]
> https://cwiki.apache.org/confluence/display/STORM/Release+0.11.0+Feature+Set
> >>
> >>
> >
>
>
--
Name : 임 정택
Blog : http://www.heartsavior.net / http://dev.heartsavior.net
Twitter : http://twitter.com/heartsavior
LinkedIn : http://www.linkedin.com/in/heartsavior