MMX Framework supports versioning on three different levels: data, model and metamodel. Which type of versioning is most appropriate in which case depends on the purpose and context of the specific case, requirements and scope of the application etc.

On data level, every instance (M1) level entity (object, relation or attribute) is equipped with built-in timestamp structure, version number and status indicator, combination of which has the capability to encode the history of events concerning the entity. Managing these histories - instantiating multiple versions of an object, querying for event history etc. - is the responsibility of an application or service. Data level versioning treats an object as an isolated entity and pays no attention to its properties or relationships. This is the simplest form of managing versioning information but it is sufficient in most cases as usually only the latest (current) incarnation of the entities are of interest to the consumers of metadata.

On metamodel level, the contents, structure and relationships subject to versioning process are part of the metamodel (M2) and are defined as special classes dedicated for this purpose. Sometimes these version classes can be descendants of a 'main' class, inheriting all or part of its properties, but usually they are completely independent classes 'on their own right' (eg. Statistical Activity/Statistical Activity Instance and Classification/Classification Version in Neuchâtel Terminology model). How to treat metamodel level versioning is completely up to the metamodel, how and why the versioning classes are defined and the purpose and context of the application.

Things get more interesting on model level. Maintaining versions of a model object requires keeping track of related properties and relations as well based on the context of the object. To create a version of an object an application or service has to take the following steps:

- create a copy of an object (MD_OBJECT) with new id and identical values of the attributes that do not change with the new version;

- add a suffix with consequent unique number to object name to distinguish between different versions (name[1], name [2] etc.); 

- create copies with identical values of all properties and property hierarchies (MD_PROPERTY) of the object being versioned;

- create copies of all relations (MD_RELATION) with any direction of the object being versioned. 

- add an instance of special relation type PreviousVersion (inherited from MMX Core) linking the new object instance to the previous version; 

Model level versioning does not apply in case of a class with subclasses as it is assumed that in that case versioning takes places on the lowest subclass level.