I can't argue with that. I was not aware that incubator was winding to a close. I thought it was just in a lull prior to the 2.0 milestone, as it had been before other releases. With that new perspective, I think I'm prepared to hold my peace. :-)
Thank you both. - Isaac On Thu, Sep 10, 2009 at 1:19 PM, Freeland Abbott <fabb...@google.com> wrote: > 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.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 -~----------~----~----~----~------~----~------~--~---
