大型系统中的软件版本控制答案

【问题标题】：Software versioning in large-scale systems大型系统中的软件版本控制
【发布时间】：2015-04-03 16:42:18
【问题描述】：

我的公司正在开发一个系统 10 年。该系统有 15 个几乎独立的子系统（它们可能使用相同的库或包或 DB），这些子系统在不同的团队中本地构建，还开发了一个主要的简单系统来读取子系统配置并构建带有菜单和子菜单的页面来自配置（带有快捷方式）。我们公司的产品就是这个主系统的exe。

很遗憾，我们公司不使用标准版本号。现在，我们决定在公司强制制定标准，我发现Semantic Versioning 是一个令人满意的标准，但我对我们的案例有一些疑问： 子系统版本的更改会如何增加主系统版本？ 通常，即使子系统发生重大更改，主系统的代码仍然不受影响。我认为主系统的变化应该影响该系统的版本号，但在这种情况下它没有意义。对于由多个子系统组成的大型应用程序的版本控制是否有任何解决方案？

【问题讨论】：

这种情况看起来像是大系统的修订，并不总是其子系统更改的结果。如果是这样，您可以在规则中写一些要点来记录每个系统构建的模块/子系统的版本。

标签： versioning semantic-versioning

【解决方案1】：

我认为您在这方面走在正确的轨道上 - 将 SemVer 版本的所有内容都视为自己的东西。

如果您需要重建更新的链接依赖项，那么至少它会是一个补丁版本更新 - 如果它们只是软链接（即，有人可以在不重建或需要修复的情况下更新子系统），那么它纯粹是一个需要更改版本号的情况。

遵循 SemVer 的想法，如果事情导致不兼容的更改，那么将最高更改拉出可能是有意义的。即 - 同时更新 5 个子系统，其中 4 个是补丁更新，还有一个是次要版本 - 您只需更新主系统的次要版本（并将它们全部放入单个更改中）。与重大变化等相同。

另一个类似的想法是，如果主构建纯粹是顶部的接口，则稍微放弃更改 - 任何次要或补丁更改只会导致次要更改，任何主要子系统更改都会导致次要 - 这样你可以保留主要用于中断前端更改等。

要记住的是，您不必完全遵循 SemVer - 一致性是此类事情的关键 - 因此您可以在合并子系统更改时更新补丁级别，并且永远不要重置它，而仅为主系统更新次要和主要版本。（有几个开源项目以这种方式工作，我只是不记得哪些是我脑海中浮现的）。

不确定它是否有用，但您可以查看一些 nodejs 软件包以及它们如何使用不同的依赖版本更新其版本 - 它们都包含了它们在 package.json 文件中使用的内容的列表以及版本以某种格式列出（即完全 xyz 或 >xyz 等 - https://docs.npmjs.com/files/package.json#dependencies）

【讨论】：

【解决方案2】：

来自 SemVer 常见问题解答：

如果我在不更改公共 API 的情况下更新自己的依赖项该怎么办？

这将被认为是兼容的，因为它不影响公共 API。显式依赖与您的包相同的依赖项的软件应该有自己的依赖项规范，作者会注意到任何冲突。确定更改是补丁级别还是次要级别修改取决于您是否更新了依赖项以修复错误或引入新功能。我通常希望后一种情况有额外的代码，在这种情况下，它显然是一个小的级别增量。

我会将此应用于您的场景，如下所示：如果您的主应用程序对其依赖的子系统进行升级而无需对其自身进行重大更改，则它应该增加次要版本或补丁版本。您不需要增加主要版本，因为它自己的公共 API 仍然被认为是兼容的。

如果主应用程序使用添加到子系统的新功能，则应该是小版本的增加。

否则，应该是补丁版本增加。

【讨论】：

【解决方案3】：

您提供了指向 MAJOR.MINOR.PATCH 的链接，并增加了
进行不兼容的 API 更改时的主要版本，
以向后兼容的方式添加功能时的次要版本，
进行向后兼容的错误修复时的 PATCH 版本
子系统中的任何更改都可能使主系统不兼容：太多而无法跟踪。
每个子系统都应该使用自己的版本。在主系统中，您应该对依赖项和自己的版本有一个概览。
您可以通过不同的方式进行管理。一种方法是使用 Maven 和 pom.xml 文件。另一种方法是使用具有不同版本的配置文件。
每个团队都可以独立开发自己的代码并分配语义版本。
也许有一天你会将共享库、包和数据库放在一个存储库中，所有团队都可以使用他们自己的 pom.xml 引用它们。
你这样灵活。您甚至可能想要创建第二个主系统（用于顶级客户或免费帐户？）并且可以更改 pom.xml 包括/排除子系统。第二个主系统将有自己的版本控制。

【讨论】：