My thoughts: - this is more risky that it will be missed if someone misses one - its more cumbersome on an individual commit - the merge is not just the patch authors knowledge, but also the trunk changers knowledge, so its not always that simple if there is a clash so it might require some discussion
I agree sooner is better (I'd probably lean to weekly in general, but the way I see the Maven dev focusing on 2.0.1, then 2.0.2 with infrequent 2.1 implementation until they are done, I think this is more manageable). - Brett Alan D. Cabrera wrote: > Brett Porter wrote, On 11/22/2005 9:07 PM: > >> - use of the flying fish technique (ie bugfix only release goes over >> to /branches/2.0.x) >> * we should merge at each point release (2.0.1, 2.0.2) back to trunk >> * can do interim merges if there are long time lines on those releases >> > > > It has always been my experience that merges back to th trunk should be > done immediately, by the original patch author, while it is still fresh > in one's mind. The problem of merging back to the trunk at the point > release becomes even worse when code has been modified in the trunk. > > > > Regards, > Alan > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
