On Thursday, November 22, 2012 6:16:54 PM UTC+1, Jens wrote: > > The steering group should clearly define what breaking changes are allowed > and which one would require a deprecation phase.
Agreed, we also need to define the duration of the deprecation phase (this is something I already put on the table, but we had other things to talk about at that time) > 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 <[email protected]> wrote: >> > On Thu, Nov 22, 2012 at 9:41 AM, Thomas Broyer <[email protected]> >> 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
