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
<[email protected]> 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
<[email protected]> 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
<[email protected]> 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 <[email protected]> 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
> <[email protected]> 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, "임정택" <[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
>
>
>
>
