Versioning allows you to identify snapshots in the lifecycle of a solution, service, or component in the runtime environment, and to be able to concurrently run multiple snapshots at the same time in a runtime environment. So what can be versioned in WID, WPS, and WESB?
A module can have a version number.
SCA export bindings in a module. SCA bindings inherit their version information from the module they are associated with.
SCA imports can specify a target version number.
Library can be versioned. Modules that use a library have a dependency on a specific version of that library, and libraries can also have dependencies on specific versions of other libraries.
Business processes.
Human tasks.
Versioning allows you to simultaneously deploy multiple versions of an SCA module to the same deployment environment. For example, if you have updated the TrackAndManageCustomerOrder business process, you can modify this process without modifying its consumers. The existing consumers will be able to seamlessly pick up the newest version of the process the moment it becomes effective. You can also have several versions of the same process co-exist on the server so that long-running processes can complete without interruption.
You can create versioned modules and libraries in WID, and these versions are for use on the server at runtime, not for distinguishing levels of completion in a development environment. By default, versioning is not enabled in WID.
Note
Enabling versioning on the module or library results in a new side file containing the version metadata—sca.module.attributes or sca.library.attributes.
In WID, to enable versioning so that all newly-created modules and libraries have versioning by default, go to Window Preferences | Business Integration | Module And Library Versions and select the IBM Supplied Version Scheme from the drop-down list. Note that you can also choose the IBM Supplied Version Scheme from the Dependency editor, as outlined in the following steps.
In WID, to enable versioning on an existing module or library, open the particular module's or library's Dependency editor and expand the Version section. As shown in the following screenshot, click on the drop-down arrow, select IBM Supplied Version Scheme, and enter a version number for the module or library as required (the default scheme uses three numbers for version, release, and modification).
A versioned SCA module must be exported from WID specifying Command line service deployment. Exporting as EAR will result in a non-version-aware EAR, just as if you had not enabled versioning. To export a module:
Right-click on it, and select Export | Business Integration | Integration modules and libraries. Proceed with the wizard by clicking on the Next button.
Versioning scheme is: version.release.modification (such as, 1.0.0).
The initial version of a module has a default value of 1.0.0. Do not change this if not necessary.
Version all libraries.
Every version of the module should be version controlled in CVS or IBM ClearCase.
Versioning scheme is: version.release.modification (such as, 1.0.0).
Update version value when:
Changes are incompatible with the prior version.
Examples can be interface and/or operation signature changed, operation removed from interface, added a required attribute to a BO, and so on.
Update release value when:
Changes being made are compatible with the prior version.
Examples can be operation added to interface or optional attribute added to BO.
Update modification value when:
Changes being made are internal changes only.
Examples include changes that have no effect on the interface, operation, or BO, performance improvements in code, and implementation changes that are internal only.
WID WTE is not version-aware. Remove the module from the WTE before working with another version of the module with the same WTE (server) instance.
Non-SCA import/export bindings are not version-aware, so must be changed manually. So when using JMS/MQ bindings, the queue names must be unique between SCA module versions. When using SOAP HTTP bindings, endpoint names must be unique between SCA module versions.
If the module contains BPEL processes that use late binding, you need to update the validFrom value. If the module contains BPEL processes that do not use late binding, you need to rename and refactor the process component. For BPEL-based components (processes, state machines), the BPEL database uses the component name and validFrom value as the unique key. To avoid conflicts, the combination of these two parts must be unique among module versions. If the process is not using late binding, the component name alone is the unique key.
For more information on module versioning in WPS, refer to