在微服务产品中应用SemVer是否有最佳实践/模式？每个微服务应该有SemVer吗？整个产品应该有SemVer吗？
示例 - 我有一个名为SuperDatabase的产品，其中包含3个名为SuperDatabaseCore，SuperDatabaseReports和SuperDatabaseSearch的微服务。
初步发布：
SuperDatabase v1.0.0
SuperDatabaseCore v1.0.0
SuperDatabaseReports v1.0.0
SuperDatabaseSearch v1.0.0
报告的小更新：
SuperDatabaseReport v1.1.0
产品现在应该是SuperDatabase v1.1.0吗？
如果以后有搜索补丁怎么办：
SuperDatabaseSearch v1.0.1
是否应该再次更改产品版本？产品版本应该完全独立于微服务吗？它应该使用SemVer吗？或者它应该没有任何版本？
答案 0 :(得分：2)
您应该独立地对服务进行版本化，微服务架构的一个好处是，您可以更新和部署系统的小部分，而不会对其他组件造成任何停机（理论上）。如果在对组件C进行更新时对组件A和B进行版本控制，则只有在更改组件时才会部署所有组件。
答案 1 :(得分：2)
我知道这是一个迟到的回应，但我想我会分享它。
我们有许多微服务，每个都有自己的semver。我们正在使用docker容器来部署甚至发布到客户端（我们发布了docker镜像）。 docker有一个清单，用于指定包含哪些微服务的版本......这是一个人工，因为我们需要选择兼容的版本。我们的devops正在计划使用kubernetes，我认为它有一个很好的依赖管理。
产品的版本（营销版）完全不同。开发不关心营销版本......他们根据整体主要/次要变化提升他们的版本。这实际上是我们发布的docker镜像的版本。
回到微服务，我们正在使用自动版本控制...所以开发人员必须通过指定更改的类型并根据构建过程破坏版本来更改日志到更改日志文件（无论是它是次要的，主要的或补丁）。一旦更改合并到主分支，分支就会自动标记该版本。所以基本上我们不断发布。
就共享库而言，我们也关注semver。我们正在利用maven范围版本来获取最新的兼容版本，如果有主要版本，则需要开发人员来升级相关应用程序。
我发现还有这两篇文章：
using a core to plug microsevices in和 having multiple concurrent instances