+1 I'm totally fine with this if people feel there are a lot of issues with shared (I can't say since I have limited time for testing.)
In general I think the best practice is to create a branch before release time (for shared and whatever is about to be released - in this case core.) Then make all crucial fixes on the branch. In fact, the branch should contain *only* crucial fixes at this time. If the fix is so important that it should go into the nightly right away then it should be merged down according to the guidelines I suggested earlier. If there are a ton of issues (as there appears to be now.) The branch can be abandoned aftter any remaining stuff on the branch should be merged down. So that is what we will do in this case. Merge it down and wait a week or two until the shared is fixed. Then start a new branch. Lets try and move quickly though. Everyone is impatient for a new release. We need to focus on fixing shared once and for all and get this release out soon. Sean ps. Due to jet lag and lots of down time I might be able to help out some. It depends on how good my internet options are in the next city I go to. On 3/10/06, Werner Punz <[EMAIL PROTECTED]> wrote: > Mario Ivankovits schrieb: > > > I may ask if its the right time to start with the release now. > > > > We have a rather young module myfaces-shared and uncover problems with > > it every day. > > I think we have to put every effort into shared so that it is clean in > > two weeks - and avoid any additional complexity. > > > > Means, we should gave us one week to fix shared (in trunk), another to > > test the trunk and then to start the release. > > I have no problems to drop the trunk in our internal production version > > - currently this is not possible. > > > > Once shared is stable I am definitely +1 to do the merging stuff during > > the release for the rare fixes which we need once the whole system is > > more stable again - which is NOT the case currently. > > > +1 for another two weeks, due to the fact that I need to do some minor > fixing stuff in Dojo as well, which would be great to have in the stable > codebase in the next realease. > > Otherwise people will maybe start to hack components on top of Dojo and > run into the problems I am going to fix on the weekend. > > > >
