向应用程序分配一个版本

在 CICS® TS 中，某些资源具有与其关联的版本。例如，云支持上下文中的应用程序需要版本和名称。还必须为要作为 CICS 应用程序或 CICS 平台的一部分安装的 CICS 束指定版本。 CICS 应用程序绑定也具有版本。这些版本与 CICS 产品版本 (例如 V 5) 不同。为什么需要这个版本，你该怎么使用呢?

必须将版本控制策略应用于 CICS 束，应用程序束和应用程序绑定，以在 CICS 环境中部署和管理更新。不能使用现有版本的应用程序束来为应用程序安装新版本的 CICS 束，并且不能将现有版本的应用程序绑定与新版本的应用程序束配合使用。每当更新应用程序的 CICS 束时，都必须更新应用程序束和应用程序绑定的版本。

对于云支持， CICS 建议基于语义版本控制的版本控制系统，如技术文件语义版本控制中所述。这种版本系统广泛应用于基于 OSGi 的项目中，如 Eclipse ，并首次出现在 CICS TS 4.2 中的用于 CICS (JCICS) API 的 Java 类库中，它使 API 或服务的作者能够清楚地描述实现中变化的性质，以便客户了解与早期版本的兼容性问题。

用于 CICS TS 应用程序， CICS 捆绑软件或 OSGi 捆绑软件的版本属性采用格式 <major>.<minor>.<micro>: 例如， 2.3.1 版本应该由负责维护相关资源 (例如，应用程序开发者) 的人员手动更新。版本应该是作为新活动的一部分进行的第一个更改。

应通过以下方式使用版本部分更改:

微型: 例如，从 1.0.0 到 1.0.1。无外部更改 (例如，错误修订)。
次要: 例如，从 1.0.1 到 1.100.0。与较早版本或外部更改兼容 (例如，现有客户机不受影响)。
您可以选择将次版本增加 100 ，而不是 1。当您希望同时运行应用程序的多个版本时，此方法很有用。例如，执行以下场景: 运行应用程序的 V 1.0.0 在生产环境中，并添加到 V 1.1.0中。一段时间内，两个版本都同时运行，没有问题。然后，在版本 1.0.0 中发现错误，需要对应用程序的外部内容进行少量更改。理想情况下，您会增加次要版本号，因为外部对象已更改，但 V1.1.0 已在使用中。如果在添加新版本的应用程序时使用 V 1.100.0 ，那么可以修复 V1.0.0 中的错误，并增加其次要版本号以反映对应用程序外部的更改。 CICS TS 使用此技术来对 JCICS API 随附的 OSGi 束进行版本化。
重大: 例如，从 1.100.0 到 2.0.0。更改与较早版本不兼容 (例如，文件记录的不同格式或除去操作)。

更改应用程序版本时，根据语义版本控制原则，新版本应反映应用程序中包含的 CICS 束中的最大更改。例如，您可以将应用程序的一个 CICS 束从 V 1.0.1 更改为 V 1.0.2(这是微版本更改) ，并将应用程序的另一个 CICS 束从 V 1.2.0 更改为 V 1.3.0(这是次要版本更改)。因此，包含这两个 CICS 束的应用程序束应该进行轻微版本更改，因此如果应用程序先前为 V 2.5.1，那么应该更改为 V 2.6.0。