Yeah, in that case I think it might be okay not to add the client-side compilation option. Would rather not do that anyways, if we don't have to, since then we'll have to go through an annoying deprecation process for the code that sets that option (unless we want to have it be redundantly available forever, or just start ignoring it).
-----Original Message----- From: Todd Lipcon [mailto:t...@cloudera.com] Sent: Thursday, March 11, 2010 6:47 PM To: thrift-dev@incubator.apache.org Subject: Re: Exception after Oneway? On Thu, Mar 11, 2010 at 6:43 PM, David Reiss <dre...@facebook.com> wrote: > > Tough call on breaking the backwards compatibility. There are a lot of > folks out there with deployed async methods that would not appreciate > breakage. > Well, it would only affect C++ and Erlang servers built with Thrift prior > to r761389. > In that case, an 0.3 release will be compatible with 0.2 (since 0.2 includes that revision). So, I'd say this seems fine to make the change now without a lot of client options, and tell people that we don't support rolling upgrade from prereleases prior to that version. -Todd > > > I wonder if we could mitigate things by making people specifically > compile client-code with an option to send ONEWAY instead of CALL > That sounds like a good way to go about it. > -- Todd Lipcon Software Engineer, Cloudera
