Going forward, I think Ray said incubator bits will either migrate into GWT proper (and be maintained and branched for releases there) or will "languish," so I imagine the advice will gradually become "don't use incubator." I take "languish" as meaning we'd probably remain stable against existing releases, but face bitrot against trunk which might become bitrot against new GWT releases, and be fixed only as cases were called out. That's my personal interpretation, though; I don't think we've declared a definition. Anything that does remain in incubator I think should have release branches, as Ray suggests... I think it does help the morass, because you can leave behind a stably working incubator against 1.6/1.7/whatever, and only need the trunk to work with a trunk of GWT.
If incubator is relatively quiet, I think that's easier... if it's noisy, then you need the incubator's current-GWT-release branch to be noisy also, and suck up the merges to incubator trunk, drag on RAD or not. But I think it's just bad news to have a given incubator branch promising to be compatible with some plural number of GWT branches, which is where we are now.... I'd rather do merges, and not have to straddle an open-ended set of differences between GWT branches. On Thu, Sep 10, 2009 at 1:06 PM, Isaac Truett <itru...@gmail.com> wrote: > > 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.comthat > > 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 -~----------~----~----~----~------~----~------~--~---
