Yes, trunk first and then branch later seems the right thing to do. The RM can choose which fixes go into branch.
thanks, -- dims On 4/14/07, Glen Daniels <[EMAIL PROTECTED]> wrote:
Hi Afkham! Afkham Azeez wrote: > Do the fixes in the branch need to be necessarily carried out on the > trunk as well. I'm asking this since we'd be merging the code in the > branch with the trunk eventually. The problem is that the longer we go without merging, the more likely it is we'll have conflicts, or heaven forbid fix the same problem twice (if someone working on trunk hasn't noticed that the bug has been fixed on the branch, say). It also becomes much more of a pain to have one person do a giant merge where they don't necessarily have intimate knowledge of all the conflicts, as opposed to the people making the individual fixes simply merge them over when they're fresh in the mind. Also, we always want the trunk to carry the latest fixes and improvements so people can move forward there without having to wait for a big post-release merge to pick up fixes. In fact, I think it likely makes the most sense to fix bugs on the trunk *first*, and then merge those changes over to the release branch, rather than the other way around. --Glen --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Davanum Srinivas :: http://wso2.org/ :: Oxygen for Web Services Developers --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
