lagom 微服务+maven 模块版本控制

Question

使用 Maven 安装脚手架时，每个模块都有一个 pom 文件。每个模块都有一个引用父项目版本的版本。
链接这些版本是整体的好习惯吗？这基本上意味着对于其中一个模块的每次更改，都需要在父模块中进行版本更新。

我有两个相关的问题：

1. 使用 git 子模块管理 vcs 是一种好习惯吗？
   我希望这些模块可以独立运行，但似乎又一次整体提升了始终运行（和部署？）所有微服务作为一个整体（我可能错了）。
2. 如何使用它管理 URL API 版本控制？假设我想更新我的 post-api 版本，但不是我的 user-api 版本。在当前情况下，两个 API 将具有相同的当前版本（父版本）。
   我希望 pom 文件的项目（发布）版本对应于 API 版本，并希望在 URL api/1.0.0/... 的路径中声明它。这样做的正确方法是什么，或者您是否普遍反对 Lagom 微服务的这种做法？

再次感谢您的帮助，并对许多问题表示歉意。
我希望这对将来的其他用户也有帮助。

Answer 1

从我能收集到的信息和我能想到的逻辑：

1) 如果我理解正确的话，我们的 VCS 会跟踪构成我们应用程序的整个相关服务树。对一个服务版本的版本升级会导致整个系统（父版本）的升级。因此，如果出现错误，可以将整个应用程序回滚到最新的稳定版本。
从操作的角度来看，我们可以批量或单独构建/部署/运行服务。因此，仍然可以为某些服务挑选和选择特定的过去版本并根据需要进行部署。
不同环境中的回归测试（或在 Conductr 的情况下使用沙箱）很重要，因为当我们没有正确管理依赖关系图时可能会发生错误（例如，忘记部署依赖于已修改的另一个服务的服务）。我假设我们并不总是希望为每次更改重新部署所有服务。
在开发方面，如果我们在每个功能的单独分支上提交我们的跨服务更改并将我们的分支部署到开发环境以在合并到 DEV 分支或发布之前进行测试，我们不需要使用 git 子模块。在团队中工作时，我看不到这里会立即出现问题。

2)https://groups.google.com/forum/#!msg/lagom-framework/_2zFx3OBH7c/uZnFSXWoAwAJ：

鼓励向前兼容的 api 设计。如果发生重大更改，请创建新版本的服务和“桥接”服务。看来我们这里没有应用 api 版本控制（无论是内部公开还是外部公开）。
这引起了我的一些担忧，也许我没有把它做好……因为我们控制着我们的客户，所以它可以工作。桥接服务让我有点担心，因为我不知道走这条路的后果。当我们控制从客户端到服务器的系统时，我认为大多数可能的不兼容问题在几个稳定版本之后都已解决，所以我想这不会有太大问题。

如果您不同意，欢迎提供反馈或替代答案。