+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 >> <aaron.doss...@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, "임정택" <kabh...@gmail.com> wrote: >> >>> +1 >>> >>> Jungtaek Lim (HeartSaVioR) >>> >>> 2015-11-12 7:21 GMT+09:00 P. Taylor Goetz <ptgo...@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 <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 >>>>>> >>>>>> >>>>> >>>> >>>> >>> >>> >>> -- >>> Name : 임 정택 >>> Blog : http://www.heartsavior.net / http://dev.heartsavior.net >>> Twitter : http://twitter.com/heartsavior >>> LinkedIn : http://www.linkedin.com/in/heartsavior >> >> >> >> >
