I am confident that r6108 fixed the problem I was having with GWT trunk last night. I think I just happened to try to build during a brief period where the build had broken. By the time r6108 had been committed, I had already moved on to other things.
I see what you're saying about incubator being bogged down by backwards compatibility. I had thought of incubator more as a place to develop new APIs rather than a place to build on pre-release APIs. The issue as it sounds to me is that when a new API develops outside of incubator (such as in GWT trunk), you want to develop/update incubator widgets with that API before it gets into a GWT milestone. Would a branch for 1.7 really help with the morass problem? If you maintain the branch, then you still have to code incubator changes against two different versions of GWT. If you don't maintain the branch, then it's not particularly useful. Going forward should the advice be "don't use incubator unless you plan to stay at the bleeding edge of GWT trunk?" I can't speak for other developers, but if that had been the case then I don't think I would've ever used incubator widgets in my work projects. Maybe I shouldn't have used them, but they've been very helpful so far. None of the widgets have been production quality to begin with, but I've been able to report bugs and get bug fixes committed, sometimes supplying fixes myself, and build from incubator trunk without worrying that I'd have to update my GWT core to a trunk build. Losing that assurance will hurt, but it won't be the end of the world. It will definitely make it harder for me to benefit from the latest incubator widget bug fixes. On Thu, Sep 10, 2009 at 11:44 AM, Ray Ryan <rj...@google.com> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
