大规模系统中的软件版本控制

Question

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

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

Answer 1

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

Answer 2

来自SemVer FAQ：

  

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

     

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

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

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

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

Answer 3

我认为你已经走上了正确的道路 - 直接用SemVer版本来对待一切事物。

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

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

另一个类似的想法是如果主要构建纯粹是一个接口在顶部稍微删除更改 - 任何次要或修补程序更改只会导致它的次要，并且任何主要的子系统更改都会导致次要 - 这样你可以保留专业，以打破前端变化等。

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

不确定它是否有用，但您可以查看一些nodejs包以及它们如何使用不同的依赖版本更新其版本 - 它们都包含它们在package.json中使用的列表具有以特定格式列出的版本的文件（即，正好是xyz或＆gt; xyz等 - https://docs.npmjs.com/files/package.json#dependencies）