Variant 1 of "consistent versioning" creates a new version of the entire object. This is only executed if the versioning type on the header is set to "consistent versioning" and the status of the object is "Released" (IZQFR). Only the header is versioned. The validity area of the previous version in the form of VALIDTO is set to the current time minus 1 second. In addition, the predecessor version is given the status "Old version" (IZQAL) after the successor version is released. This means that the status of the previous version can no longer be revoked and editing of the node is no longer possible.

The versioning type of the children is irrelevant, because all children of the object are not versioned, but moved to the successor version. Therefore, there is neither a predecessor nor a successor version. This means that these nodes have an original relation (relation type "Original" (O) ) to their new and old parents simultaneously. However, the moved children get as OGUID the GUID of the new head and they keep as PREVOGUID the OGUID of the first version of the object. For this reason, the children cannot be edited on the predecessor object. However, they can still be used.

Example

As an example, "consistent versioning" is carried out on the header using an object. The status "Released" (IZQFR) is available in the status profile. The header and the children have the version management "consistent versioning". If the object is released, "Change status → Create version" is selected on the header via the context menu.

image-20240606-082036.png

The main similarities and differences between the two versions of the head can be seen in the following text and figures. The successor version of the head has the same VNR as the previous version. The version number has been increased by one. The validity area of the successor version in the form of the VALIDFR has been adjusted to the current time. The validity area of the predecessor version in the form of VALIDTO was set to the current time minus 1 second.

Previous version:

image-20240606-082046.png

Follow-up version: 

image-20240606-082056.png

All children of the old object are moved to the new object. Therefore, there is neither a predecessor nor a successor version of the child. The same child nodes are used in both objects. Accordingly, there is no change to the scope, VNR, or version number. The child nodes have RELATTYP = O on the old and the new object. The following figure shows an example of this for one node of the object.

Nodes on the old object:

image-20240606-082106.png

Nodes on new object:

image-20240606-082117.png

After the successor version of the object has been released, the status of the previous version of the header changes to "Old version" (IZQAL).

Previous version:

image-20240606-082129.png