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 >> >> >
signature.asc
Description: Message signed with OpenPGP using GPGMail
