Brett Porter wrote, On 11/24/2005 4:23 PM:
My thoughts:
- this is more risky that it will be missed if someone misses one
This is not as likely if the commits are made to both lines at the same
time. Also, there will be times when it will not make sense to apply
the branch change in the trunk. You want the original patch author to
make that investigation and decision at the time of the checkin not a
"third party" branch merger at the time of a branch merge.
- its more cumbersome on an individual commit
Not more cumbersome. Waiting to do the work at the uber merge merely
postpones the inevitable. Blind merges that just dump whatever is in a
branch into the trunk are always dangerous without careful scrutiny;
performing this due diligence makes it the same, usually more, amount of
work as individual multi branch commits.
- 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
And you want to know of the clash and have that discussion asap, at the
time of the checkin, not later. Issues like this need to be resolved
before the trunk evolves further and while things are still fresh in
everyone's mind.
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).
The paradigm I espouse applies to what ever product management style
that is in place. The issues that I raise are not as relevant for more
mature product lines that do not change that radically. But it has
always been my experience that a "blind" merge at the end of a branch
release is always more work and error prone than "multi branch" checkins.
Just my 2 cents. :)
Regards,
Alan
- 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]
