如何处理依赖关系源版本问题

你不能既有蛋糕又吃:

• 要么依赖一个稳定的版本库,然后引用它(无论它位于何处)

• 或者你将永远依赖“最新和最伟大的”,然后引用一份副本

磁盘空间并不是一个真正的问题-显然,您需要在开发人员机器上至少有一个正在使用的lib的本地副本,如果它是“正确版本控制的”代码或“主干的头部”,这并没有什么区别。而且,当它总是“主干的头部”时,您可能会使用一些版本控制系统(如git或svn)来获取库,因此每当您更新本地副本时,您将只从repo中提取更改,而不是“完整的100 MB”。

然而,为了使构建在源代码的每个版本中都具有可复制性,您应该将所有依赖项与源代码一起进行版本化。如果您使用的是第三方LIB,您可以

• 依赖供应商为您提供项目期间使用的版本,并期望他们在未来10年左右为您提供这些版本

• 或者,保留您所使用的第三方libs的每个版本的副本(可能也将它们放在您自己的源代码repo中)。这是我一直喜欢的专业发展方法,谁知道图书馆供应商是否还在下周、下个月、明年维护他的资料?

以下是如何同时吃蛋糕(参见量子物理学):

1. 使用自己的分布式版本控制系统(git、hg、bazaar等)在全球各地维护您的依赖项(库)。(见注1)
2. 在项目文件夹中维护依赖项版本数据库(文本文件),并在每次生成时更新它。(格式: MyLibrary commit-hash-or-version )

Project将始终使用最新版本的依赖项。如果在某个时候编译失败(例如,当您在3年后尝试编译项目时),

1. 获取上一次成功构建时使用的依赖项版本
2. 在临时位置使用该哈希创建依赖项的签出。
3. 将临时位置作为构建过程中的依赖项路径。

显然,这种“返回成功点”的过程可以很容易地自动化。

注1:依赖项并不仅仅是源代码,它们可能只是一些二进制格式的工具。在这种情况下,依赖关系管理器挂钩应使用 --version 参数(或适用于该工具的参数),获取版本,附加到 dependencies.txt 文件显然,您应该准备好能够获得该工具的旧版本,以防将来需要它。