Versioning provides the ability for the runtime environment to identify snapshots in the lifecycle of a process application and to be able to concurrently run multiple snapshots at the same time.
Think of the process application as a container. All snapshots, deployment, and versioning are handled at that container level, not at the level of the artifacts within the container. Snapshots are managed from the Process Center console.
Changes are dynamically saved to the Process Center repository at the tip of the working track. The process application remains at that tip level until you decide to create a snapshot (sn1). A process application snapshot can be deployed to a process center server or a process server for testing, staging, or production.
If you make changes and want to deploy a new version, you need to create a new snapshot (sn2). You can either remove sn1 or leave it running on the server when you deploy sn2.
Version context is the metadata that identifies a version. You assign that identifier, but IBM recommends using a three-digit numerical version system in the format <major>.<minor>.<service>. See the topics about naming conventions for a more detailed description of this versioning scheme.
IBM® Business Process Manager assigns a global namespace for each process application. The global namespace is specifically either the process application's tip or a specific process application snapshot. The version name used by the server cannot be longer than seven characters, so the assigned name will be an acronym that uses characters from the snapshot name that you assigned. Snapshot acronyms will be identical to their snapshot names if the snapshot names conform to the recommended IBM VRM style and are not more that seven characters. For example, a snapshot name of 1.0.0 will have an acronym of 1.0.0, and a snapshot name of 10.3.0 will have the acronym of 10.3.0. The snapshot acronym will be guaranteed to be unique within the context of the process application within the scope of the Process Center server. For that reason, you cannot edit the snapshot acronym.
To version process applications and toolkits that are stored in the Process Center repository, you can save and name snapshots. Doing so enables you to compare one snapshot to another to find differences. For example, if a developer fixed a problem with a service and took a snapshot of its containing process application or toolkit at that point, and then a different developer made several additional changes to the same service and took a new snapshot, the project manager could compare the two snapshots to determine which changes were made when and by whom. If the project manager decided that the additional changes to the service were not worthwhile, the project manager could revert back to the snapshot of the original fix.
Typically, you take a process application snapshot every time that you are ready or potentially ready to deploy to production or to test integration. To deploy to a stand-alone process server, you must take a snapshot of the process application. It is a slightly different story for toolkits; you take a snapshot of a toolkit when you are ready for that toolkit to be used by process applications. Afterward, if you want to update the toolkit, you must take another snapshot of "tip" when you are ready, and then the owners of process applications and toolkits can decide whether they want to move up to the new snapshot. The tip is a special snapshot, and the only kind of snapshot in which you can change contents, but you can run it only on the Process Center server. You cannot deploy a tip to the Process Server.
You can deploy the same version of a process application to multiple clusters within the same cell. To differentiate among these multiple deployments of the same version of the process application, create a snapshot for each deployment and include a cell-unique ID in the snapshot name (for example, v1.0_cell1_1 and v1.0_cell1_2). Strictly speaking, each snapshot is a new version of the process application (from a pure life cycle management perspective), but the content and function are the same.
When you deploy a process application to a cluster, an automatic synchronization of the nodes is performed.