我们正在开发由不同但示意性耦合的系统组件组成的管理SOA系统：
模式是公分母。 UI和各种分解的Web服务在其上进行协作。模式存储过程中还存在大量的业务逻辑。
发布周期固定在商定的日历日中，该日历日由业务需求和资金决定。新版本将包含客户认可的预定批次的更改。每个发行版均以 major.minor.patch 的方式提供顺序的版本号。从某种意义上说，版本号是特定系统组件的实际版本号的抽象。考虑下面的图表，其中显示了一些发行版：
Version 8.2 changes:
----------------------
Schema: 8.0 → 8.2 (change)
UI: 8.1 → 8.1 (no change)
Web Service: 8.1 → 8.1 (no change)
Version 8.2.1 changes:
----------------------
Schema: 8.2 → 8.2 (no change)
UI: 8.1 → 8.2.1 (change)
Web Service: 8.1 → 8.1 (no change)
Version 8.3 changes:
----------------------
Schema: 8.2 → 8.3 (change)
UI: 8.2.1 → 8.3 (change)
Web Service: 8.1 → 8.1 (no change)
Version 8.4 changes:
----------------------
Schema: 8.3 → 8.3 (no change)
UI: 8.3 → 8.4 (change)
Web Service: 8.1 → 8.4 (change)
用外行的话来说，发行版可能影响任何数量的系统组件，但至少会影响其中的一个。这导致在版本控制下各个系统组件的版本号不同且不连续。要在各种环境中维护出色的安装及其版本表，需要付出巨大的努力。我们为当前和早期版本托管并行开发环境，以涵盖保修事务。这是简化的“环境表”的示例：
--------------------------------------------------------
| Version | Schema | UI | WS |
--------------------------------------------------------
| 8.4 | 8.3/build# | 8.4/build# | 8.4/build# |
--------------------------------------------------------
| 8.3 | 8.3/build# | 8.3/build# | 8.1/build# |
--------------------------------------------------------
| 8.2.1 | 8.2/build# | 8.2.1/build# | 8.1/build# |
--------------------------------------------------------
| 8.2 | 8.2/build# | 8.1/build# | 8.1/build# |
--------------------------------------------------------
在进行并行开发和执行合并时，很难对版本进行推理，因此是excel。无条件地将组件版本号与发行版本号同步会很方便。另一方面，总是不希望将组件重新部署到生产中。在这些前提下，管理和记录版本控制的最佳策略是什么？