On Tue, 2007-01-02 at 14:53 -0500, Steve Vinoski wrote: > > 4. It is understood that the implementation of the new message class > > will take a week or two to complete, and that the trunk will be > > non-functional until these changes are complete. At a minimum, > > checkins > > should compile, but may not pass all functional tests. > > Rather than breaking trunk, why not do the work on a branch, and > merge it when it works? > > > 5. A coordinated and simultaneous effort will be required to > update > > the > > C++, Java and Python codebase to implement and use the new frame and > > message classes. The other clients can follow later. > > Taking a branch would allow everything to be coordinated on the > branch and simultaneously merged when ready. > > --steve
Overall, I don't think it matters much whether the effort occurs on a trunk or on a branch... Certainly placing such a change on a branch is more traditional. I would only add that making the change on the trunk makes the effort more visible, and has the effect of focusing the effort required to make the change. Branches tend to be "invisible" to many developers, and can be ignored until the merge. Part of the plan here is to make the change as visible as possible, and to involve as many as possible in the updates. Kim
