我的公司正在开发一个系统 10 年。该系统有 15 个几乎独立的子系统（它们可能使用相同的库或包或 DB），这些子系统在不同的团队中本地构建，还开发了一个主要的简单系统来读取子系统配置并构建带有菜单和子菜单的页面来自配置（带有快捷方式）。我们公司的产品就是这个主系统的exe。
不幸的是，我们公司不使用标准版本号。现在，我们决定在公司强制制定一个标准，我发现Semantic Versioning是一个令人满意的标准，但在我们的案例中我有一些问题： 子系统版本的更改将如何增加主系统版本？通常，即使子系统发生重大更改，主系统的代码仍然不受影响。我认为主系统的变化应该影响该系统的版本号，但在这种情况下它没有意义。对于由多个子系统组成的大型应用程序的版本控制是否有任何解决方案？
您提供了 MAJOR.MINOR.PATCH 的链接，
当您进行不兼容的 API 更改时增加 MAJOR 版本，当您
以向后兼容的方式添加功能时增加 MINOR 版本，当
您
进行向后兼容的错误修复时增加 PATCH 版本
子系统可能会使主系统不兼容：太多无法跟踪。
每个子系统都应该使用自己的版本。在主系统中，您应该对依赖项和自己的版本控制有一个概述。
您可以通过不同的方式进行管理。一种方法是使用 Maven 和 pom.xml 文件。另一种方法是使用具有不同版本的配置文件。
每个团队都可以独立开发自己的代码并分配语义版本。
也许有一天你会将共享库、包和数据库放在一个存储库中，所有团队都可以使用他们自己的 pom.xml 引用它们。
你这样灵活。您甚至可能想要创建第二个主系统（用于顶级客户或免费帐户？）并且可以更改 pom.xml 包括/排除子系统。第二个主系统将有自己的版本控制。
从 SemVer 常见问题解答：
如果我在不更改公共 API 的情况下更新自己的依赖项，我该怎么办？
这将被认为是兼容的，因为它不会影响公共 API。显式依赖与您的包相同的依赖项的软件应该有自己的依赖项规范，作者会注意到任何冲突。确定更改是补丁级别还是次要级别修改取决于您是否更新了依赖项以修复错误或引入新功能。我通常希望后一种情况有额外的代码，在这种情况下，它显然是一个小的级别增量。
我将其应用于您的场景如下：如果您的主应用程序对其依赖的子系统进行升级而无需对其本身进行重大更改，则它应该增加次要版本或补丁版本。您不需要增加主要版本，因为它自己的公共 API 仍然被认为是兼容的。
如果主应用程序使用添加到子系统的新功能，则应该是次要版本增加。
否则，应该是补丁版本增加。
我认为您在这方面走在正确的轨道上 - 从字面上将 SemVer 版本的所有内容视为自己的东西。
如果您需要重建更新的链接依赖项，那么至少它会是补丁版本更新 - 如果它们只是软链接（即，有人可以在不重建或需要修复的情况下更新子系统），那么这纯粹是一个想要的情况更改时的版本号。
坚持 SemVer 的想法，如果事情导致不兼容的更改，那么拉出最高的更改可能是有意义的。即 - 同时更新 5 个子系统，4 个是补丁更新，一个是次要版本 - 您只更新主系统的次要版本（并将它们全部放入单个更改中）。与重大变化等相同。
另一个类似的想法是，如果主构建纯粹是顶部的接口，则稍微放弃更改 - 任何次要或补丁更改只会导致次要更改，任何主要子系统更改都会导致次要 - 这样您就可以保留主要用于破坏前端更改等。
需要记住的是，您不必完全遵循 SemVer - 一致性是此类事情的关键 - 因此您可以在合并子系统更改时更新补丁级别，并且永远不要重置它，同时更新次要主要版本仅适用于主系统。（有几个开源项目以这种方式工作，我只是不记得哪些是我脑海中浮现的）。
不确定它是否有用，但您可以查看一些 nodejs 包，以及它们如何使用不同的依赖版本更新其版本 - 它们都包含了它们在 package.json 文件中使用的内容的列表，其中列出了版本某些格式（即，正好 xyz 或 >xyz 等 - https://docs.npmjs.com/files/package.json#dependencies）