对多组件项目进行版本控制的最佳方法是什么

我有一个由5个主要组件组成的程序。我发现标准版本编号太过局限，因为我想查看每个组件的版本。

除了分别列出每个人以外，还有没有人找到一种简单的方法来做到这一点？

我们的产品存在完全相同的问题，因此我们决定为每个组件进行单独的版本编号，并且该产品版本仅是由特定修订版本的各个组件组成的营销版本。

我们有一个“系统发行版”，它是描述组件特定配置的标准版本号，然后一个单独的文件列出了该特定系统发行版的各个组件版本。客户说的是5.2.1，但如有必要，我们可以查找单个版本。通常，对于主要版本，我们会同步所有单个版本，以便所有内容均从同一分支号中重新构建。

版本控制是一个与基于组件的应用程序开发无关的问题。您要对每个组件进行版本控制，或者对整个应用程序进行版本控制。

Microsoft的一个很好的版本控制模式是：

major version.minor version.build number.revision

例如，您可以看到.NET平台中的DLL文件具有2.0.3600.1之类的版本。

因此，我建议您首先确定是否要对整个系统或其组件进行版本控制。如果要对整个系统进行版本控制，则在每次集成之后，构建整个项目，并增加构建号部分。如果不是，则只需对构建中的每个组件进行版本控制。

注意版本控制，这可能会杀死您:-)不要试图使事情变得过于复杂。

我认为以下方法可能会为您提供帮助：

使用所需的任何版本控制架构分别对每个组件进行版本控制。根据您的评论，我了解到您已经安装了VCS。我还假定每个组件都有一个保存其版本的文件（对吗？）。每天/每周一次（以对您的团队更有效的方式），将标签添加到VCS中的最新修订中，以将该修订标记为最新的正式修订（并可选地增加超级修订编号）。现在，您可以查询带有该标签的VCS版本，然后在该正式版本中查找组件的版本。

如果只想在本地使用，请编写一个小脚本，该脚本将汇总代码中存储位置的每个组件的版本。

如果您想使它更加新颖，则在进行标记后，您可以查看属于每个组件的文件，并考虑到可以识别属于特定组件的文件。如果有任何更改，请增加该特定组件的版本。另一种方法是手动执行此操作。另一种选择是将分支和合并与版本跟踪结合在一起。

大多数版本号使用由市场营销驱动的主要和次要版本，因此您不能使用它们来跟踪单个组件的版本。简而言之，您需要查找该版本的其他部分，以用于跟踪单个组件的版本，并保留主要和次要版本号以跟踪整个程序包。

如果您遵循类似于Microsoft模式的方法：

major-version.minor-version.build-number.revision

您可以使用.revision来跟踪每个单独组件的版本，并可以使用次要版本号和主要版本号来跟踪完整的产品更改。

如果您遵循的模式与此类似：

Major-Version.Minor-Version.Build-Number

您将必须使用内部版本号来跟踪各个组件的版本。

整本书都是关于版本控制软件的。

这是我使用的一种方法。

每个部分都有以下形式的版本：

重大发展

这些都是从0开始的数字。

对于正式发布（即发布给客户），根据政策，开发部分必须始终为0。

专业因行销决策而增加。

通过向市场发布功能集来增加次要功能。

例：

• 我开始在新组件上进行开发，因此我的版本号将是0.0.1。例如，当我从办公桌上放下时，供内部测试时，开发编号上升到0.0.2、0.0.3等。

• 我将这个新东西以1.0.0的形式发布到市场上，其中从开发结束到发布的唯一允许更改是更改版本号（例如0.0.43-> 1.0.0）。

• 一些新功能将被添加。我开始在1.0.0基线上工作，添加了这些功能，因此我发布给同事进行测试的版本是1.0.1、1.0.2，依此类推。

• 下一功能将从1.1.0版本发布到市场。

• 市场营销人员认为下一件大事将是真正的大事，因此它将以2.0.0的形式出现。我从1.1.1开始工作，一直到1.1.x，然后以2.0.0发行。

如此循环重复。

对于每个组件，此方法都可以追溯祖先。

在源（和对象）修订管理系统内部，使用分支和标签（标签，无论您今天使用的术语是什么）来管理开发。

然后，您的修订控件可以完全分别管理每个组件，并为每个组件分别具有开发分支和标签/标签。或者，您也可以将它们捆绑在一起，在这种情况下，您可能希望按工作包进行分支-但一定要按每个组件的发布来进行标签/标记（并且在进行操作时，对所有内容进行标签/标记，而不仅仅是对组件的标签/标记）。组件。这样，您就可以获得当时所有状态的快照。）

您的发布过程可能需要仔细考虑。使用这种方法的确包括一些手动步骤，这可能是不可取的-这完全取决于您的构建系统如何将版本号放入最终对象中。对于许多嵌入的代码，其中版本号只是命名的数字（例如，在C代码中定义为＃），您别无选择，只能以任何方式手动执行所有操作。具有出色GUI的桌面平台通常使这一切变得更加友好。

摘要

对我来说，版本软件的唯一可靠方法是使用版本控制系统中的哈希或变更集标识符。

总体构建版本号可能很有用，但只有在拥有构建服务器和/或对每个发行版进行签名的情况下，才真正保证其唯一。但是对于我们许多人来说，这根本不可行。

如果您的项目分散在多个版本控制存储库中，则还需要构建一种机制，使您的用户界面可以查询每个从属存储库并将其哈希报告给用户。

个人经验的例子

在前雇主的一个项目中，我们（内部）客户修改软件并重新编译时遇到了问题，我制定了一个流程，将杂乱的哈希值编译到每个应用程序和库中。每当启动软件时，都会通过查询所有软件组件来构建修订字符串。

当您转到“关于”页面时，将显示此修订字符串，并在每次启动应用程序时将其写入日志文件。它的形式为：

Application name     (6a72e7c61f54)
    Library1         (b672a13a41e1)
        Library2     (9cc35769b23a)
    Library2         (9cc35769b23a)
    Library3         (4e9f56a0186a+)
        Library2     (9cc35769b23a)
    Library4         (2e3b08c4ac76)
        Library1     (b672a13a41e1)
            Library2 (9cc35769b23a)

由此，我可以很容易地看到他们修改了Library3，并且没有将这些更改提交到存储库中，因此他们使用的是不受控制的代码。我还可以将散列值与当前的测试系统进行比较，因此我可以识别出它们是否已将（例如）Library1恢复为较旧的版本。

这意味着无论何时他们报告一个错误，我总是可以完全重建问题发生时正在使用的代码，或者至少可以肯定地知道我无法复制该设置。

有关我使用的构建系统的更多详细信息，如何完成此工作，遇到了什么问题以及人们建议避免这些问题，请查看我的Stack Overflow问题。

注意：仅当使用修订控制系统时，如果给定的工作目录可以包含混合的文件，则保证给定的哈希确保在工作目录中产生相同的文件集（例如git和mercurial），此系统才真正可行以及来自多个修订版本（例如svn）的目录，则所有关于工作目录状态的押注都将关闭，并且该方法将完全无效。