我目前正在与其他五位开发人员一起开展一个项目，我们正在为我们的版本控制系统使用 subversion。我们已经确定，在我们的软件的第一个版本之前，我们有 12 个里程碑。我们使用版本号（0.1 到 0.12）和描述性标签标记了里程碑。例如：
但是，每隔几个里程碑就有一个由以前的里程碑组成的外部版本。所以，我们最终会得到如下结果：
这些里程碑中的每一个都可以并行开发，但它们也需要并行进行 QA。我们通过在 subversion 中为每个里程碑创建分支来实现这一点，这些里程碑只用里程碑的版本号标记。自动化系统独立构建每个里程碑，并使用构建应用程序的里程碑号和 subversion 修订号对应用程序进行版本控制。版本号在应用程序中显眼地显示，这样当 QA 团队查看版本号时，他们可以将其与特定的里程碑联系起来，并知道哪些需要进行 QA，哪些不需要。一旦里程碑通过 QA，它将被合并到主干中，任何正在进行的开发都将使用最新代码进行更新。
但是，有一个假设（正确如此），即版本号的增加包括所有以前的版本。不幸的是，对于上述方案，这可能不会发生，因为一个里程碑可能会在另一个里程碑之前完成。例如，0.3 可能会在 0.1 之前完成。这意味着我们将拥有一个不包含 0.2 或 0.1 功能的内部 0.3 版本。
这是我的问题。当多个并行版本（内部或其他方式）可能不按顺序完成时，我如何智能地对软件进行版本控制？
我认为你不能，因为你的目标是相互冲突的——并行开发和连续的里程碑。
要么推迟 0.3 版本的发布，直到 0.1 和 0.2 完成，要么您必须考虑另一种分配里程碑编号的方法。
也许您可以根据里程碑的内容来命名里程碑，而不是使用 0.1 等，这会增加清晰度并消除混乱。