In the following, the results after versioning the child in an object consisting of only a head node and a child node are explained.

For versioning to be executed on the child, the direct parent node must be editable.

However, if "consistent versioning" is set on the header and on the child, further rules apply, which are explained on the next page Consistent Versioning (H).

The following points apply:

The child is versioned and the versioning type on the header is set to "versioning inactive", "weak versioning", "versioning as copy" or "versioning as copy, consistent scope".

  • If the versioning type "weak versioning" is set for the child, no new version of the header is created when the child is versioned. The child receives a successor version with the OGUID of the object as OGUID and PREVOGUID. In addition, the validity area is set to the current time in the form of the VALIDFR. The child's predecessor version remains unchanged. This also means that the status of the predecessor version remains at "Released" (IZQFR), even if the successor version is released. In particular, the release of the previous version can be revoked.

  • If the versioning type "Versioning as copy" is set for the child, the status of the previous version is also set to "old version" (IZQAL) after the new version is released. This status can no longer be revoked and the node can no longer be changed subsequently. 

  • For the versioning of the child with the versioning type "versioning as copy, consistent validity area" or "consistent versioning", the validity area of the child's previous version is set to the current time minus 1 second in the form of the VALIDTO. Here, it is also no longer possible to undo the status of the previous version and subsequently change the node.

If the release is not set at the status profile:

  • "Weak versioning" → If the release is not available, the status of the previous version does not change when an activity is performed on the successor version.

  • "Versioning as copy"/ "Versioning as copy, consistent scope" / "consistent versioning" → If the release is not available, the status of the previous version does not change when an activity is performed on the successor version. This means that the previous versions no longer receive the status "old version" (IZQAL).

Those children of the children are copied unless the node to be versioned is versioned consistently. Then all children of the children are moved to the successor version of the node to be versioned.

Example

In this example, the child is versioned. The status "Released" (IZQFR) exists in the status profile. The header has the versioning type "weak versioning" and the child has the versioning type "versioning as copy, consistent validity area". The following screen shows this object.

image-20240606-081925.png

After the child has been released, "Change status → Create version" is selected on the child via the context menu.

image-20240606-081939.png

A successor version of the child is created with the status "In Creation" (IZQER). The header has remained unchanged.

The main similarities and differences between the two versions of the child can be seen in the following text and figures. The successor version of the child is assigned a next higher version number. The VNR remains the same. The validity area of the successor version in the form of the VALIDFR is set to the current time. The validity area of the predecessor version in the form of VALIDTO is set to the current time minus 1 second.

image-20240606-081949.pngimage-20240606-081958.png

After the release of the successor version of the child, the status of the previous version changes to "Old version" (IZQAL).

image-20240606-082009.png