Evolve & Tagging
Sébastien Gautrin
sebastien.gautrin at gmail.com
Tue May 10 12:45:37 UTC 2016
On 10/05/16 14:36, David Douard wrote:
> in which the proposed solution it listed as point 3.5.6. I know Matt
> really is conservative about bw compat breakages, but I really think
> it's the best solution in this list. My 2c
Considering the issue is related to evolve, affecting the behaviour of a
non-evolve command in such a way would not seem a good idea to me.
Considering the purpose of evolve, the “natural” expectation would be
that after evolving the code base the affected tag point to the
replacement target (option 3.5.1 in the list).
The case of tags that are not descendants of the tagged commit (which
probably does not happen that often) could be potentially be handled by
marking the tag commit as unstable if its target is obsolete, and
evolving it would replace it by a tag commit pointing to the correct target.
As Pierre-Yves David mentioned, the correct approach is not
straightforward, but option 3.5.3 (Warn when rewriting a draft tag)
could be implemented first, letting end users manually handle the
evolution (creating a new tag commit to replace the “obsolete” one after
evolution), until a proper solution is found.
More information about the Evolve-testers
mailing list