5

我目前正在与其他五个开发人员一起开发一个项目，我们正在使用 subversion 作为我们的修订控制系统。我们已经确定，在我们的软件首次发布之前，我们有 12 个里程碑。我们使用版本号（0.1 到 0.12）和描述性标签标记了里程碑。例如：

  • 0.1 - 导航
  • 0.2 - 搜索
  • 0.3 - 用户管理

但是，每隔几个里程碑就会有一个由之前的里程碑组成的外部版本。因此，我们最终会得到以下内容：

  • 0.1 - 导航
  • 0.2 - 搜索
  • 0.3 - 用户管理
  • 0.4 - 阿尔法 1

这些里程碑中的每一个都可以并行开发，但它们也需要并行进行质量检查。我们通过在 subversion 中为每个里程碑创建分支来做到这一点，只需用里程碑的版本号标记。自动化系统独立构建每个里程碑，并使用里程碑编号和构建应用程序的颠覆修订号对应用程序进行版本控制。版本号显示在应用程序的显着位置，因此当 QA 团队查看版本号时，他们可以将其与特定的里程碑联系起来，并知道哪些需要进行 QA，哪些不需要。一旦里程碑通过了 QA，它将被合并到主干中，并且任何正在进行的开发都将使用最新代码进行更新。

但是，有一个假设（正确地），版本号的增加包括所有以前的版本。不幸的是，对于上述方案，这可能不会发生，因为一个里程碑可能在另一个里程碑之前完成。例如，0.3 可能会在 0.1 之前完成。这意味着我们将有一个不包含 0.2 或 0.1 功能的内部 0.3 版本。

这是我的问题。当多个并行版本（内部或其他）可能不按顺序完成时，我如何智能地对软件进行版本控制？

4

3 回答 3

2

我不认为你可以，因为你有相互冲突的目标——并行开发和连续的里程碑。

要么在 0.1 和 0.2 完成之前推迟发布 0.3 版本，要么必须考虑另一种分配里程碑编号的方法。

也许您可以根据里程碑命名而不是使用 0.1 等，这样可以增加清晰度并消除混淆。

于 2008-10-08T22:19:44.190 回答
1

由于内部里程碑没有真正的顺序，我更愿意为外部版本保留次要版本号，给出反映该功能的分支名称，并添加 subversion 修订以标识内部版本。您的外部版本获得了非常干净的 0.1、0.2、0.3 版本，而 0.2.1234 的内部版本可以很容易地在 Subversion 中准确地检查在外部版本 0.2 和此版本之间合并到主干中的内容。

于 2008-10-08T22:24:12.823 回答
1

我有点困惑为什么你要用数字来区分分支；根据特性（例如车门、车辆方向盘）命名每个分支，并使用版本号跟踪每个分支的进度（车门 v0.1、0.2 等）。

但是，如果您打算稍后集成，除非您非常非常小心，否则这将是地狱。您可能想考虑管理这可能变得多么疯狂。

于 2008-10-08T23:13:31.273 回答