Martin Sebor wrote:
Travis Vitek wrote:
Martin Sebor wrote:
[...]
I think we need to decide if trunk is supposed to be a copy of
4.2.x or if it's for development of future versions. If the
latter, there's no problem with keeping tests like it there
as long as they're passing or as long as there's an entry in
xfail.txt. We just need to remember not to merge them (and
fixes for them, if they're incompatible) out to 4.2.x.
So, which is it? Do we keep trunk as a development version of
4.2.x or do we make changes on it that are incompatible with
4.2.x?
I'm thinking that all work for 4.2.1 should be done on the 4.2.x branch,
and future work should be done on trunk until an appropriate branch has
been created. That way we avoid having to be careful about bulk merges
from trunk to 4.2.1... Everything that is on 4.2.x should be safe for
trunk.
Unfortunately, I think that would mean that we would need to do nightly
testing on the 4.2.x branch, possibly in addition to trunk.
Right, that's a big problem. Another problem with this approach
is that it has the potential to destabilize the branch.
The second problem can be mitigated by tagging the branch when
it's known to be stable. I don't think there's anything we can
do about the first problem except alleviate it by implementing
a more intelligent test harness. I'm not sure we have cycles
for that...
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?
Is there some convention or process we could put in place that
would make the bulk merge issue less painful? I wake up in the
middle of the night thinking about how we're going to manage
it for 4.2.1. Maybe it won't be so bad, but it does seem like
it will be a lot work and could be pretty error prone.
Martin
