应该如何对相互关联的软件包进行版本控制？

Posted 2023-03-07

【中文标题】应该如何对相互关联的软件包进行版本控制？

【英文标题】：How should inter-related software packages be versioned?

【发布时间】：2019-06-25 18:07:16

【问题描述】：

一些开源项目进行组合发布，其中每个包（库）的版本号增加到相同的版本。

Java 中的示例是：

org.springframework com.fasterxml.jackson org.hamcrest

这意味着一些包可能会获得一个新版本，即使它们没有改变（也没有改变它们的依赖项）。我不认为这违反语义版本控制。

我看到的好处是：

用户可以使用单一版本进行监控和升级 所有用户都可能使用相同的库组合

缺点：

尽管要下载的包没有更改，但仅使用众多库之一的用户可能会收到有关“更新”的通知 如果很多用户只使用一个子包，那么一个版本的所有错误报告都是针对一系列版本的，这很难跟踪。恢复到以前的“不同”版本以避免错误变得更加复杂。

【问题讨论】：

相关：***.com/questions/38496022，***.com/questions/45417741

【参考方案1】：

单一版本控制的一种替代方法是使用 BOM（材料清单）。 存在不同的 BOM 概念：

BOM 可以列出多个依赖项以包含在其版本中（例如 Linux apt Meta-packages） 如果包含依赖项，BOM 可以定义要使用的依赖项的版本（和其他限制）（例如，Java Maven dependencyManagement BOM 部分）

BOM 允许声明哪些库版本的配置（组合）已一起测试，并允许不同的用户组都使用相同的配置，从而有助于错误报告和重现性。

不过，并非所有软件分发和构建系统都同样支持 BOM 概念。

【讨论】：

在某些地方这被称为虚拟包。它没有内容，只有依赖。

大多数 Linux 分发包管理器使用虚拟包来安装包组。我没有具体的参考。

我通过链接在我的答案中添加了元包。我为虚拟包找到的唯一解释是针对 Debian：debian.org/doc/manuals/debian-faq/…，但似乎这是解决不同问题的不同概念。