Obsolete Pages{{Obsolete}}
The official documentation is at: http://docs.alfresco.com
VersioningDesign Document
This article contains design documentation relating to the versioning features found in the Alfresco documenent management repository. For more information on versioning in the AVM (Advanced Versioning Manager) repository used in the Web Content Management application and other areas, please see versioned directories.
Back to Specification
General requirements
The following is a list of the general requirements for versioning within our repository:
- Versioning should be an optional feature of the repository which can be 'installed' as a packaged feature with all the required code and definitions encapsulated within.
- Standard versioning functionality should be supported (create, get, restore, revert, etc).
- A simple public API should be available.
- The implementation of the underlying version storage mechanism should be componentised such that it can be changed with minimum impact.
The versionable aspect
In order to make a node versionable the versionable aspect must be applied, either at runtime or in the node's type defintion.
The versionable aspect contains information about the current version that the node relates to and is required by the version service when working with a node.
The version service
The version service provides the main interface to access the version capabilities of the repository.
The version service API hides the underlying version storage mechanism and provides a number of well defined version operations.
These include:
- createVersion - this creates a new version of the referenced node which is placed at the end of the appropriate version history. If the node has no version history then one is created and this version is considered to be the initial version.
- getVersionHistory - this gets the version history that relates to the node referenced.
- deleteVersionHistory - this deletes the version history for a versioned node.
- getCurrentVersion - gets the current version for a referenced node.
- revert - reverts the state of a referenced node to that of a previous node.
- restore - restores a previously deleted node from a version in its version history.
Version meta-data and version labels
Meta-data can be specified when creating a new version. This information is stored in the version store against the created version.
The meta-data is made up of names and values and can contain anything the user application requires. The meta-data can later be retrieved from the Version object.
Typical version meta data set by the user application could be a description of the version, the nature of the change, the importance of the change, etc.
In addition to the meta-data set by the user application there is some system meta-data that is also available.
Most notably each version has a version label which is used publicly to identify the version. The version label gives, within the scope of the version history, a unique label for the version. It is this label that is placed in the versionable aspect to indicate the related current version for a node.
The generation of the version label can be customized by creating a version label policy behaviour and registering it in place of the default version label policy. This gives applications flexibility to determine their own version labeling policies.
The default version label policy uses 1.1, 1.2, style of progressive version labels, moving to 2.0 if the version is considered to be a major change. This is indicated in the version meta data which the version label policy has access to.
Versioning Behaviour
JSR-170 Versioning Notes
