I built incubator against trunk last night. Are you still seeing trouble there? The problem on our end has been that having to maintain code that works both with trunk and with the previous release makes it very difficult to iterate rapidly on incubator code. What was supposed to be a place that we could rapidly develop new features instead turns into a morass where forward progress is twice as hard a normal. That's why UiBinder in particular never moved to incubator.
Our expectation is that new features will be either developed directly in trunk (e.g. UiBinder), or else in separate projects on code.google.com that can determine their own policies on compatibility and contributors (e.g. Gin). The items that live in incubator already will either gradually move to trunk or languish. It sounds like we need to think a bit harder how to handle the stuff that hasn't graduate yet, but which is still in use. My knee jerk is to cut a 1.7 branch just before the patch that killed off StyleInjector. How does that sound? rjrjr On Thu, Sep 10, 2009 at 8:28 AM, Isaac Truett <itru...@gmail.com> wrote: > > [oops - +gwtc] > > > Hi, Ray, > > I appreciate the drive to move forward and I applaud jumping on > opportunities to remove redundant code. > > The reason this policy was important, to me at least, is that it > provided a baseline to work against. The code in the incubator can be > very useful (I use PagingScrollTable extensively and used DatePicker > from incubator before it graduated) but it's also risky because the > code is still experimental and subject to change. The assurance that > those changes would be compatible with a packaged and released GWT > build (even just a milestone) meant that I could build incubator from > trunk and pick up the latest features and bugfixes as long as my > project tracked the latest GWT build. Because of the GWT policies on > deprecation and backwards compatibility, this has been fairly easy in > practice. As it stands now, incubator will not compile except against > GWT trunk, which is also notoriously unstable (it wasn't building as > recently as last night, which I see was corrected this morning). This > presents a much higher risk for those of us using incubator code. > > It also becomes harder to work on the incubator itself when it has to > compile against GWT trunk. I wanted to look into issue #267 last night > and I was stymied by GWT trunk not being in a buildable state. Not an > insurmountable obstacle, but one that seems unnecessary to me. > > - Isaac > > > On Thu, Sep 10, 2009 at 11:03 AM, Ray Ryan <rj...@google.com> wrote: > > Hey, Isaac. > > That policy has proven very difficult to live with. (And to tell you the > > truth I forgot about it.) > > The reasoning here was that we have released incubator jars that work > with > > 1.7 and no plans to issue further ones before 2.0 MS1 lands. Should it > prove > > necessary to go back and do so we can go back and branch. > > In the meantime, we were faced bugs due to FastTree in particular being > tied > > to the old StyleInjector while new development was moving to the version > in > > GWT. We saw the opportunity to delete redundant code and took it. > > Is this going to cause problems for anyone? > > rjrjr > > > > On Wed, Sep 9, 2009 at 3:26 PM, Isaac Truett <itru...@gmail.com> wrote: > >> > >> Last year, Emily stated that it would compile against the "latest > >> gwt-milestone and gwt-trunk". There hasn't been a 2.0 milestone that > >> I've seen, so under the policy from last year StyleInjector should not > >> have been removed in revisions 1712-1715. > >> > >> So, what's the current policy for incubator trunk compatibility? > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
