Versioning

An important and unusual feature of Lynicon is that it has a generic versioning system. The basic concept is that every content item can have multiple versions. These are indexed by the ItemVersion class, which is a name/value dictionary. Each name index represents a different versioning system. For instance, the Publishing versioning system has an index for whether the version is the published one whose values are true or false.

The diagram indicates a typical versioning setup. This contains 3 versioning systems, Existence, Published and Partition. In each system, there are different versioning values.  In this case, Existence can be Exists or Existed, Published can be true or false, and Partition can be 1 or 2.  The versioning setup creates a space of versions, the systems being the dimensions, the values being the positions along those dimensions.

The diagram illustrates how content items can exist within the version space.  Each versioning system has rules defining how content items can exist within it.  In this case, Existence defines that the same content item cannot exist in adjacent exists and existed positions.  In other words, it disallows two versions of the same content item existing where one has Existence = Exists and the other has Existence = Existed and all the values in the other versioning systems are equal.

The rules for Published specify that different copies of same content item can exist in one, the other or both adjacent true and false positions.

The rules for Partition specify that the same content item can exist in all partitions, or one specific partition, but different copies cannot exist in different partitions.

Note that it is possible for any type of content item to opt in or opt out of any versioning system.  This means each content type has an associated set of versioning systems which need values to specify the version of an instance of it.

The Elements of a Versioning System

A number of different kinds of classes are associated with managing any particular version system.  For instance the Publishing versioning system has a module called Publishing, which when registered at startup, activates the various features of this system.  The central versioning manager class VersionManager is told about the properties of this versioning system using an inheritor of the Versioner class, PublishingVersioner.  There is an IVersionable interface which expresses the availability of the metadata on a content container which is needed to store and persist whether the contained item is the published or unpublished version.

Note that a versioning module when registered will only apply to content types whose containers fulfill the versioning interface (e.g. IPublishable) and the versioning may be further restricted to a subset of those content types.  So be aware that for any content type, it may be completely unversioned, or only have versioning within some systems.

Working with Versions

Within a web request, Lynicon will automatically determine what the current version is for the request according to code in the Versioners for all currently registered versioning modules.  You can get this ItemVersion value from VersionManager.Instance.CurrentVersion, or VersionManager.Instance.CurrentVersionForType(type t) to get the current version with any version indexes not applicable to the given type removed.

All Lynicon systems will act as if only the content in the current version exists unless this behaviour is intentionally overriden.  In many cases this will not be necessary.  Generally when an administrator is logged in to Lynicon and viewing content or administrative pages, they will be able to use the version controller on the bottom control bar on the right to switch the values of the current version.

You can determine the version of a summary, content item or content container simply by constructing an ItemVersion using any of these as the argument e.g. new ItemVersion(o).  Summaries also have the version as a property: Summary.Version.