Made a mistake and put something on private that never should have been there. Here is the discussion in full so far. In response to Jungtake removing the nocamel option will change set_bar/get_bar in the generated thrift code to setBar/getBar. So any thrift object that clients interact with will need to make similar changes. - Bobby ----- Forwarded Message -----From: Bobby Evans <ev...@yahoo-inc.com>To: "priv...@storm.apache.org" <priv...@storm.apache.org>Sent: Monday, November 7, 2016, 3:37:50 AM CST Subject: Re: [DISCUSS] breaking changes in 2.x Sorry you are right, I put in the wrong mailing list. I feel dumb. Will move it to dev. - Bobby
On Sunday, November 6, 2016, 2:18:33 AM CST, P. Taylor Goetz <ptgo...@gmail.com> wrote:Can we move this discussion to dev@? There doesn't seem to be anything sensitive about the subject. -Taylor On Nov 6, 2016, at 1:28 AM, Jungtaek Lim <kabh...@gmail.com> wrote: Regarding breaking change, I'm OK to break backward UX compatibility if we're sure that it gives better UX. And since we're talking about next major, if we don't do it now, we might have no chance to do the near future. For 1) this should be corrected, and for 2) I'm not sure how it affects to end-users, but it would be better to address if it doesn't hurt user codes much. 3) I think expected user impact is similar to what we did it for adding dependencies to shade list. Then it doesn't look matter to me. Thanks,Jungtaek Lim (HeartSaVioR) 2016년 11월 5일 (토) 오후 11:01, Bobby Evans <bo...@apache.org>님이 작성: I have been working on getting some of clojure code translated to java, and I have run into a few issues that I really would like to address, but will impact users. Because 2.x has not been released yet technically these should be OK, but I want to get feedback from others before I spend a lot of time on them or even file a JIRA. 1)WHAT: The thrift NodeInfo.port should be a single long, not a set of longs.USER IMPACT: it is exposed to end users through the profiling request API. BACK COMPAT: it is possible, but I would prefer not to. 2)WHAT: Using 'nocamel' when generating thrift makes generated exceptions less useful and the API less java like.USER IMPACT: users when upgrading would need to modify some API calls when setting/reading thrift objects.BACK COMPAT: most older clients should still work for a lot of things 3) WHAT: split up storm-core so we have class path separation between daemons and a true client.USER IMPACT: Users may need to include new dependencies to get what they want. Old topologies may not get access to everything that they want.BACK COMPAT: we could leave some old dependencies in place that are not needed, but why? If we do all of these it is likely that profiling requests from an old client will not work, but for the most part a 1.x client would still work with 2.x. - Bobby
