The steering group should clearly define what breaking changes are allowed and which one would require a deprecation phase.
GWT is a growing framework and if it contains clearly wrong internal dependencies of classes this should be fixed. I would guess it would simplify the build process (and mavenization) and you don't risk to make the dependency situation more complex than it should be. If its only renaming a package from X to Y then, as a developer, I am totally fine if my code becomes broken after updating GWT because I could fix that via some IDE automatism like organize imports or a global search/replace on import statements. As long as its well documented in the release notes, so it does not hit me like a surprise, this should be fine. -- J. Am Donnerstag, 22. November 2012 17:03:22 UTC+1 schrieb Thomas Broyer: > > On Thu, Nov 22, 2012 at 4:22 PM, John A. Tamplin <j...@jaet.org<javascript:>> > wrote: > > On Thu, Nov 22, 2012 at 9:41 AM, Thomas Broyer > > <t.br...@gmail.com<javascript:>> > wrote: > >> > >> >> 1. CRITICAL: java.lang.NoClassDefFoundError: > >> >> com/google/gwt/core/client/GWTBridge > >> >> > https://code.google.com/p/google-web-toolkit/issues/detail?id=7527 > >> >> > >> > Regarding the server calling client issue -- is it correct that the > >> > client > >> > code is actually forked via super-source so that it works properly on > >> > client or server? > >> > >> I believe so yes. Not sure all those classes have super-sources but I > >> don't think it's a problem either. > >> > >> > If so, maybe we should rename it to shared, > >> > >> That'd be a breaking change. These are mostly internals, but I bet at > >> least a few people are using c.g.g.user.client.rpc.core.* classes in > >> their own custom field serializers, so I guess it's too late for a > >> rename (and I'm not in the mood to introduce an indirection where all > >> (deprecated) *.client.* classes would just delegate to their > >> *.shared.* counterparts). > > > > > > It doesn't seem that hard to add the redirection (and it should impose > only > > minimal overhead in those cases, just the class ids), and it avoids > > indefinitely using *.client.* code on the server. It should be the case > > that if you ever see server code referencing client classes it is an > error, > > and if we leave things like this around then we won't ever get away from > it. > > The RemoteService interface might be more problematic, but still > doable I guess (you made the change with many I18N interfaces). > Note that I didn't say it would be hard to add the indirection, only > that if I'm the one making the client.GWT → shared.GWT change (as I > proposed to do), I'll do just that for the 2.5.1 timeframe. > I wholeheartedly agree the client → shared renaming is something to > put on the roadmap though. > > > Also, regarding breaking changes, what exactly is the criteria for what > is > > acceptable? You have an outstanding change that would break any code > that > > previously passed a Target to something accepting HasText, so I'm not > sure I > > know what level of breaking change is acceptable and what benefit is > > required. > > Ha, good call. > Ideally, I think the HasText interface would be pulled in a module of > its own that I18N could inherit. With a bit of bad faith, I could > argue that AutoDirectionHandler is newer than GWT-RPC so the chances > of breaking someone's code are lower (it's still 2 years old though), > I also believe it's much less widely used than GWT-RPC (particularly > the case of passing a Target to something accepting a HasText), but of > course you're right. > As a side note, I introduced another breaking change in JSONP, > widening the return type of getCallback: > > https://gwt-review.googlesource.com/#/c/1230/2/user/src/com/google/gwt/jsonp/client/JsonpRequest.java > > Maybe the solution here would be to extract AsyncCallback in a module > of its own too. > > -- > Thomas Broyer > /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/> > -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
