+0.9 The code should be frozen once all the examples work. Now, there is a major bug ( MYFACES-528) that mail that dataTables, buffers, and some other components do not work ok, due to the resolution of MYFACES-509 (StateManager.saveSerializedView must throw an IllegalStateException when View contains duplicate IDs). We could build a release candidate but we cannot release without a solution to this bug. The other option is not to include the patches applied for MYFACES-509 (everything worked before, but we did not check for duplicated id's).
Regards, Bruno 2005/9/7, Abrams, Howard A <[EMAIL PROTECTED]>: > +1 > > > -----Original Message----- > > From: Sean Schofield [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, September 07, 2005 10:24 AM > > To: MyFaces Development > > Subject: Release decisions > > > > I just fixed an important stumbling block in the build script so now > > it should be possible to build a release *without* the sandbox stuff > > (and without the build crashing.) There have been a lot of changes to > > the HEAD during the past week, so I'm not sure how we should proceed. > > > > My thinking is that we should rebuild the 1_0_10 tag/branch with the > > newest code and just heavily test. I think there is too much stuff in > > the HEAD that we would want. But at some point we need to freeze the > > 1.0.10 code. > > > > So I propose that I make a new 1.0.10 branch off the latest code and > > that we use that to build a release candidate. Only the most > > important bugs (such as missing stuff from the release bundle) would > > then be addressed in 1.0.10. Last minute requests for fixing specific > > bugs will be fixed on the trunk but they won't go into 1.0.10. > > > > Can I get a few +1's on that? > > > > sean > > > > >
