Travis Vitek wrote:
Martin Sebor wrote:
It occurs to me that even if most work were done on the release
branch(es) the changes would still need to merged only in the
opposite direction: from each branch to trunk and/or to other
branches. I'm afraid I don't see how the merging problem can
be avoided. Do you?
I don't see the merge itself as the most serious problem. The trouble is
trying to figure out what changes can be merged out to 4.2.x from trunk.
I believe that we currently have some changes that aren't suitable for
4.2.x on trunk. When someone goes and tries to do the merge out, they
have to make sure they do the merge correctly and they have to be
careful to not merge changes that are incompatible with the target
branches compatibility requirements. That is what I'm worried about.
Same here.
If the merging was going from 4.2.x to trunk, then the compatibility
issue is moot.
Good point. The only problem here, and it's probably the one that
led to the current convention of making changes on trunk first,
before merging them to 4.2.x, is that we've had a good share of
changes that we thought were appropriate for 4.2.x that turned
out not to be.
The release process document tries to deal with this problem by
allowing changes on a release branch at first, until the RM has
decided it's time to start stabilizing the branch (Feature Freeze).
At that point the branch becomes RTC for everyone but the RM. In
practice what I expect this to mean is that development (including
bug fixing) will proceed on trunk (or other branches) with the RM
being responsible for doing the merges.
Since we haven't reached a "Feature Freeze" yet we should be able
to follow the process. The only two obstacles are: no test results
for 4.2.x, and our propensity to make incompatible changes. As I
said I'll take care of the first. I'm not sure how to handle the
second except by freezing the branch. Which will bring us a full
circle...
Martin
