+1. On 11/11/15, 2:27 PM, "Derek Dagit" <der...@yahoo-inc.com.INVALID> wrote:
>+1 > > -- >Derek > > >----- Original Message ----- >From: P. Taylor Goetz <ptgo...@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 <ptgo...@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....@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:ptgo...@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 >>> >>> >> >
