Can you provide a hypothetical example for how #3 might break something for users?
It seems like most of the cases of backward incompatibility are not typical/average use cases, and that rolling upgrades would only be affected in certain edge cases. If that’s the case then I’m fine with the proposed changes. -Taylor > On Nov 7, 2016, at 10:43 AM, Bobby Evans <[email protected]> wrote: > > 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 <[email protected]>To: > "[email protected]" <[email protected]>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 > <[email protected]> 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 <[email protected]> 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 <[email protected]>님이 작성: > > 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 >
