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, "임정택" <[email protected]> wrote: >+1 > >Jungtaek Lim (HeartSaVioR) > >2015-11-12 7:21 GMT+09:00 P. Taylor Goetz <[email protected]>: > >> 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 <[email protected]> >>wrote: >> > >> > >> >> On Nov 11, 2015, at 9:28 AM, Bobby Evans >><[email protected]> >> 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 < >> [email protected]> 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:[email protected]] >> >> 发送时间: 2015年11月11日 6:16 >> >> 收件人: [email protected] >> >> 主题: [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
