Mercurial 中的发布管理 - [major].[minor].[bugfix] 版本控制，支持旧的主要版本答案

【问题标题】：Release management in Mercurial - [major].[minor].[bugfix] versioning with supporting older major versionsMercurial 中的发布管理 - [major].[minor].[bugfix] 版本控制，支持旧的主要版本
【发布时间】：2012-06-24 08:25:12
【问题描述】：

我一直在探索有关 Mercurial 发布管理的不同答案，并且几乎找到了正确的方法。但是，我只需要一些帮助来正确处理它，以便一切都在我的脑海中很好地点击。

这是我们公司需要的：

1) 将使用版本控制方案 {major.minor.patch} 进行开发

2) 命名分支和标签将用于管理发布（例如，与克隆存储库相反）

3) 在开发 3.0 版时，我们可能需要支持较旧的主要版本。例如，如果在 2.1 版中发现错误，我们将需要修复它（在 2.1.1 版中）并一直合并回当前的 3.0 版

研究了不同的选项和答案后，Steve Losh 的以下great answer（刚刚复制了下面的变更集树）可能是我们需要的，但我不知道如何在 2.1.1 上工作并一路合并如果后者已被标记，则默认返回 3.0？

$ hg glog -l 1000    
@       changeset:  25:efc0096f47c0  tip
|       summary:    Added tag 3.0 for changeset d1a7fc3d7d77
|
o       changeset:  24:d1a7fc3d7d77  3.0
|\      summary:    Merge in the redesign changes.
| |
| o     changeset:  23:b5b69d24c8f7 3.0-dev
| |     summary:    Finish 3.0 redesign.
| |
| o     changeset:  22:4c2f98fac54b 3.0-dev
|/|     summary:    Merge in the latest changes to 2.1/mainline.
| |
o |     changeset:  21:37df04521032
| |     summary:    Added tag 2.1 for changeset 39ecc520fc0a
| |
o |     changeset:  20:39ecc520fc0a  2.1
|\ \    summary:    2.1 development is done.
| | |
| o |   changeset:  19:208f3f9236af 2.1-dev
| | |   summary:    Finish the 2.1 work.
| | |
| | o   changeset:  18:4a024009a9d6 3.0-dev
| | |   summary:    More redesign work.
| | |
| | o   changeset:  17:00c416888c25 3.0-dev
| |/|   summary:    Merge in changes from the 2.1 branch to keep the redesign current.
| | |
| o |   changeset:  16:a57e781a0db1 2.1-dev
| | |   summary:    More 2.1 work.
| | |
| | o   changeset:  15:ddeb65402a61 3.0-dev
| | |   summary:    More redesign work.
| | |
+---o   changeset:  14:90f5d7a8af9a 3.0-dev
| | |   summary:    Merge in the fire fixes.
| | |
| o |   changeset:  13:78a949b67bb9 2.1-dev
|/| |   summary:    Merge in the fire fixes.
| | |
o | |   changeset:  12:6dfe9d856202
| | |   summary:    Oh no everything is on fire, fix it in the mainline.
| | |
| o |   changeset:  11:86767671dcdb 2.1-dev
| | |   summary:    Smaller changes for 2.1.
| | |
| | o   changeset:  10:25dec81d2546 3.0-dev
| | |   summary:    Work more on the redesign.
| | |
+---o   changeset:  9:42c7d689fb24 3.0-dev
| |     summary:    Start working on a complete redesign.
| |
| o     changeset:  8:3da99186ca7d 2.1-dev
|/      summary:    Start working on 2.1.
|
o       changeset:  7:9ba79361827d
|       summary:    Added tag 2.0 for changeset 755ed5c5e291
|
o       changeset:  6:755ed5c5e291  2.0
|\      summary:    Merge in the dev branch for 2.0.
| |
| o     changeset:  5:44a833fcc838 2.0-dev
| |     summary:    Finish work on 2.0.
| |
| o     changeset:  4:d7ba6aae1651 2.0-dev
|/|     summary:    Merge in the critical fix.
| |
o |     changeset:  3:968049f1b33a
| |     summary:    Fix a critical bug on the main branch.
| |
| o     changeset:  2:917869609b25 2.0-dev
| |     summary:    More work on the new version.
| |
| o     changeset:  1:f95798b9cb2e 2.0-dev
|/      summary:    Start working on version 2.0.
|
o       changeset:  0:8a3fb044d3f4
        summary:    Initial commit.

换句话说，通过上述变更集树/版本，是否可以在我们已经开始处理 3.0 的同时处理 2.1.1 修复？我的意思是如果 3.0 已经被标记，我们如何将 2.1.1 合并回默认值？我在这里错过了什么吗？如果没有，是否有更适合我们的方式来根据我们的要求管理发布？如果您可以为场景提供变更集树的类似快照，那就太好了。

提前非常感谢。你们摇滚。

【问题讨论】：

标签： version-control mercurial branch dvcs release-management

【解决方案1】：

根据您维护多个发布版本的要求，我会考虑一种不同的分支策略，它使用default 分支进行开发，并且每个主要版本都有一个分支。这在this page 上进行了描述 - 它还有一个关于如何处理重大修复的部分。

我做过一个与上面类似的例子：

@    changeset:   13:3d6ac57cce61
|\   tag:         tip
| |  parent:      9:5953138c3f87
| |  parent:      12:9691c48d79f2
| |  user:        steve.kaye
| |  date:        Tue Jun 26 08:39:42 2012 +0100
| |  summary:     Merge bug fix
| |
| o  changeset:   12:9691c48d79f2
| |  branch:      V3
| |  user:        steve.kaye
| |  date:        Tue Jun 26 08:35:23 2012 +0100
| |  summary:     Added tag 3.1 for changeset e49d9a6bb459
| |
| o    changeset:   11:e49d9a6bb459
| |\   branch:      V3
| | |  tag:         3.1
| | |  parent:      7:5354c406c68a
| | |  parent:      8:00dfa7869e8c
| | |  user:        steve.kaye
| | |  date:        Tue Jun 26 08:35:20 2012 +0100
| | |  summary:     Merge bug fix
| | |
| | | o  changeset:   10:a84c532ce507
| | |/   branch:      V2
| | |    parent:      8:00dfa7869e8c
| | |    user:        steve.kaye
| | |    date:        Tue Jun 26 08:31:09 2012 +0100
| | |    summary:     Added tag 2.1 for changeset 00dfa7869e8c
| | |
o | |  changeset:   9:5953138c3f87
| | |  parent:      5:80b80eb9581b
| | |  user:        steve.kaye
| | |  date:        Tue Jun 26 08:30:41 2012 +0100
| | |  summary:     Start work on next version
| | |
| | o  changeset:   8:00dfa7869e8c
| | |  branch:      V2
| | |  tag:         2.1
| | |  parent:      4:6c4a68f3c073
| | |  user:        steve.kaye
| | |  date:        Tue Jun 26 08:29:56 2012 +0100
| | |  summary:     Fixed a bug in V2
| | |
| o |  changeset:   7:5354c406c68a
| | |  branch:      V3
| | |  user:        steve.kaye
| | |  date:        Tue Jun 26 08:24:52 2012 +0100
| | |  summary:     Added tag 3.0 for changeset 3f3a006aacdd
| | |
| o |  changeset:   6:3f3a006aacdd
|/ /   branch:      V3
| |    tag:         3.0
| |    user:        steve.kaye
| |    date:        Tue Jun 26 08:23:54 2012 +0100
| |    summary:     Version 3.0 ready for release
| |
o |  changeset:   5:80b80eb9581b
| |  parent:      2:21cf96f3ed91
| |  user:        steve.kaye
| |  date:        Tue Jun 26 08:22:47 2012 +0100
| |  summary:     Start work on next version
| |
| o  changeset:   4:6c4a68f3c073
| |  branch:      V2
| |  user:        steve.kaye
| |  date:        Tue Jun 26 08:20:07 2012 +0100
| |  summary:     Added tag 2.0 for changeset 666cc4453281
| |
| o  changeset:   3:666cc4453281
|/   branch:      V2
|    tag:         2.0
|    user:        steve.kaye
|    date:        Tue Jun 26 08:19:43 2012 +0100
|    summary:     Version 2.0 ready for release
|
o  changeset:   2:21cf96f3ed91
|  user:        steve.kaye
|  date:        Tue Jun 26 08:18:31 2012 +0100
|  summary:     More work on the new version
|
o  changeset:   1:6177b193da7c
|  user:        steve.kaye
|  date:        Tue Jun 26 08:18:06 2012 +0100
|  summary:     Start work on version 2.0
|
o  changeset:   0:51cc3c0590f9
   user:        steve.kaye
   date:        Tue Jun 26 08:17:27 2012 +0100
   summary:     Initial commit

如你所见，我有三个分支。 default 是新开发完成的地方，然后我决定它已经准备好发布，所以我创建了一个 V2 分支并将其标记为 2.0。然后我继续在default 上工作，直到当我分支到V3 并将其标记为3.0 时，我决定它已准备好发布。然后我发现了一个错误，发现它是在第 2 版中引入的，所以我将它修复在 V2 分支上并标记为 2.1。然后我将该修复程序合并到 V3 并将其标记为 3.1，然后将 V3 合并到 default 以在开发代码中获取修复程序。

如果您从最旧的版本开始，则更容易在分支之间移植修复程序。这使您可以更轻松地将该修复合并到较新的分支。如果您首先在 default 中修复它，则无法将该修复合并到 V2 或 V3，因为您将获得旧版本中的所有新功能以及错误修复。

请注意，您仍然拥有与其他分支策略一样多的头 - 一个 default 一个用于 V2 和一个用于 V3，但如果您维护多个版本，它们将排列得更整齐。要获得软件版本 2 的最新版本，您只需执行 hg up V2，而在此之前您需要找出最新版本 2 是什么，然后更新到该版本。

【讨论】：

非常感谢史蒂夫的出色帮助。你摇滚。
我正在编写一个 Ruby 脚本来自动执行此操作：gist.github.com/rcook/6064683。请注意，这假设发布分支被命名为“v.”，尽管它可以很容易地修改为与其他命名约定一起使用。

【解决方案2】：

链接问题的第二段说：

完成 2.0 后，将 2.0-dev 合并到默认值并将结果标记为 2.0。

据此，我认为这个想法是，在您准备好发布它之前，您不会标记3.0。如果你已经发布了它，那么2.1.1 的修复程序不会进入3.0，它会进入3.0.1 并且你的工作流程不会有问题。

此外，您还可以移动标签，因此如果您发现自己标记3.0 太早，您可以使用-f 标志将其移动到hg tag。

【讨论】：

感谢您的回答。我可以看到如何将以前版本的错误修复合并到当前版本中。但是这种情况呢：错误修复是 1.1.1，当前版本默认标记为 5.7。我们如何确保在 1 和 5 之间的所有版本中修复此错误：版本 2.x 3.x 和 4.x？谢谢
假设 1.1.1 分支不包含您在其他分支中不需要的任何内容：您可以在 2.x 分支，在 1.1.1 中合并并标记。然后你会为 3.x 和 4.x 做同样的事情。如果它确实包含更改，您不希望您做同样的事情，但hg graft 更改而不是合并。
非常感谢史蒂夫，您的帮助非常宝贵。如果我错了，请纠正我，但在我看来，使用这种方法，您将永远无法关闭分支 2.x 3.x 和 4.x，因为将它们合并回默认值为时已晚？我的理解正确吗？对于所有主要的发布分支，是否会有多个负责人采用这种方法？如果是这样，也许整个工作流程不正确，我们需要改变它吗？
我不认为该工作流对于维护多个实时发布的系统来说看起来不太好，因为您只使用一个分支进行发布，因此3.0 有效地取代了2.1。它可以工作，但会变得混乱，最终可能很难跟踪哪个版本是第 2 版的最新版本。我将 default 作为开发，每个公共版本都有一个分支，并在发布时标记它。您仍然有尽可能多的头，但每个头都是一个命名分支，因此更容易跟踪。
我用不同的分支策略添加了另一个答案。