CentraSite's versioning capabilities enables you to maintain multiple versions of the same object.
Versioning an object creates a clone of the object. When you version an object, CentraSite copies the source object with all of its attributes and then increments the version number in the "cloned" target object. Additionally, CentraSite establishes a "supersedes" relationship between the new version of the object and the old one. Among other things, this relationship enables you to view and manage all versions of an asset from the asset's Versions profile in CentraSite Control.
Other than the differences described above, the new version is treated just as though it were a new object. If it is of a type that is governed by a lifecycle model, the new version of the object enters the initial state of that model (just like any new object of that type). Ownership of the new version is given to the user who generates the new version. Consequently, the new version of the object becomes part of that user's organization. Additionally, the instance-level permissions for the new version are reset (the permission settings from the source object are not copied to the new version).
You can create versions of the following types of objects:
Design/Change-Time Policies
Run-Time Policies
Lifecycle Models
Assets (except Virtual Services; see Revising a Virtual Service)
Whether a particular type of asset can be versioned depends on whether the Enable Versioning property is enabled for the type. To version an asset, this property must be enabled in the asset's type definition.
Revisioning is an optional feature that you enable or disable for the registry. When you enable the revisioning feature, CentraSite automatically generates a minor version of an object every time an update is made to the object. (All previous revisions are retained when a new one is created.) Revisioning enables you to reference or revert back to a specific revision of an object.
Note:
When you enable the revisioning feature, CentraSite maintains
revisions for all objects in the registry, not just objects that are versioned.
In some API-related documentation for CentraSite, a revision is referred to as a checkpoint.
CentraSite maintains two version identifiers for a versioned object: a system-assigned identifier and a user-assigned identifier.
The system-assigned identifier is a version number that CentraSite maintains for its own internal use. CentraSite automatically assigns this identifier to an object when a version of the object is created. The system-assigned identifier is numeric and always has the format MajorVersion.Revision. The MajorVersion number is incremented by one each time you create a new version of the object (e.g., 1.0, 2.0, 3.0). If the revisioning feature is enabled for your registry, the Revision number is incremented when updates are made to the object (e.g., 1.0, 1.1, 1.2). You cannot delete or modify an object's system-assigned identifier.
The user-assigned identifier is an optional identifier that you can assign to a specific version of an object. This identifier does not need to be numeric. For example, you might use values such as "V2 Alpha" or "V2.1 Build 0921" to identify a particular version of an object.
CentraSite does not permit you to modify a policy (design/change-time or run-time) or a lifecycle model while it is active. To modify an active instance of these types of objects, you must first deactivate it. However, doing this results in a period of time during which the policy or lifecycle model will not be enforced.
To avoid a gap in enforcement, you can use the versioning feature to modify these types of objects. Instead of deactivating the existing policy or lifecycle model, you generate a new version of the object and make your changes to the new version. When you are ready to put the updated policy or lifecycle model into effect, you simply switch the new version to the "Productive" state. When you do this, CentraSite automatically deactivates the old policy or lifecycle model and activates the new one.
For more information about versioning policies and lifecycle models, see Modifying a Design/Change-Time Policy, Modifying a Run-Time Policy and Versioning or Replacing a Lifecycle Model.
It is not necessary to version an asset to make minor changes to its metadata (e.g., the addition of a supporting document, a change in the Description attribute, the addition or removal of a particular classifier or association). Nor should you generate versions for each incremental revision of an asset that is produced during its development cycle.
You should only add a new version of an asset to the registry when you have a new implementation of the asset that is incompatible with the asset's existing consumers. For example, if a provider updates (or intends to update) a Web service in a way that "breaks" the existing applications that use the service, then you should create a new version of the asset in the registry. Such changes would include modifications to the namespace assignments, message descriptions, interface definitions and/or operation signatures in the service WSDL. It would also include changes to the implementation of the service that do not explicitly affect the WSDL, but nevertheless affect the way in which an existing consumer application interacts with the service. For example, a service that returns an expanded set of result codes or generates a different form of customer ID might break an existing consumer application even if the interface defined in the service WSDL did not change. In short, you want to create a new version of a service asset for any new implementation of the service that is incompatible with consumers of the existing service.
Note:
Be aware that sometimes versioning one asset will necessitate the
versioning of another. For example, if an XML schema changes, and that schema
is imported by a Web service, you will need to generate a new version of the
XML schema and a new version of the Web service that references it.
If a provider creates an implementation of a service that does not introduce compatibility issues with consumers of the existing service (e.g., bug fixes or performance improvements), you do not need to generate a new version of the service asset in CentraSite. Likewise, you do not necessarily need to version a service if a provider simply adds operations to the existing implementation. You can represent this type of change by just updating the existing asset in the registry.
When you version an asset that is governed by a lifecycle model, the new version of the asset enters the initial state of the lifecycle. If necessary, you can modify this behavior using design/change-time policies.
For example, if the lifecycle model for an asset type includes preliminary steps such as Analysis, Planning and Architectural Design, you might want to bypass these steps when a new version of an asset is created. You can do this by executing a design/change-time policy that switches a new version of an asset to an alternate path in the lifecycle model. For details, see Creating a Different Lifecycle Path for a New Version of an Asset.
When you deploy a new version of a Web service, you must plan for transitioning existing consumers to the new version. The approach you use depends on how you intend to add the new service to your existing operational environment. You might, for example, choose to host both the old and new versions of the service for a period of time. Or you might require existing consumers to upgrade to the latest version of the service, and then, at an agreed upon hand-over date, replace the existing service with the new one. In either case, you should take steps to proactively notify existing consumers when a new version begins its development lifecycle so that they can take steps to adapt to the changes as necessary. You can use CentraSite to identify the existing consumers of the service and notify the consumers manually or you can create policies to do this automatically when a new version reaches a particular state in its lifecycle.
After a new version of an asset is placed into production, new consumers should be discouraged from using the older versions of the asset. Applying a lifecycle model that includes the "Deprecated" state is a good way to indicate to users that an asset has been replaced by a newer version. As a best practice, you should always switch an older version of an asset to the deprecated state as soon as a new version of the asset is placed into production.
An instance of an asset in CentraSite represents the finished deliverable that was produced (or will be produced) by a specific development project or release cycle. CentraSite is not intended to be used to chronicle every incremental build or internal version of an asset that a team of developers generates during a development cycle. However, when you register an asset in CentraSite, you might want to include in its metadata an attribute that identifies the asset's corresponding set of files in the source-control system. For example, when you place a service in production, you might want to attach a build number, branch ID or submission label to the asset in CentraSite to identify the specific set of source-code files that the asset represents. You could define a custom attribute to hold this identifier or you could use the user-assigned version identifier for this purpose.
To keep the registry at a manageable size and reduce clutter, you should delete older versions of assets when they are no longer active. To do this, you can use the purge feature that is provided on the asset's Version profile. (If you do not see the Version profile for an asset, you will need to edit the asset's type definition to enable it.)
