On 06/11/2013 12:26 PM, Christopher wrote:
On Tue, Jun 11, 2013 at 12:05 PM, Josh Elser<josh.el...@gmail.com> wrote:
>The person who implements the workaround in Version1 should ensure that when
>Version1 is merged into Version2, the correct code is present in Version2.
I'm not sure that's a sufficient solution, because this means that the
branch for Version2 may stick around with effectively no change from
its last tag other than history, and you can't simply update the tag
to update the history, can you? Either it sticks around for a very
long time, or it goes away and eventually somebody else is going to
have to resolve that potential merge conflict when fixing the next bug
that comes around (which maybe applies to both).
I think I already addressed this concern with Mike later in this thread,
but I'll restate for completeness:
Even if a merge from v1 to v2 is a no-op in terms of changes, the fact
that a non-no-op change in v1 merits a no-op change in v2 is important,
and thus this is important for the developer to record with a merge.
The lifetime of the v2 branch is then subject to the same circumstance
we've talked about previously.
