Release Changes

You have several options for release changes operations:

You can trigger a release changes operation for individual elements or subtrees.
You can trigger a release changes operation by the context menu in the browser view, list view or search result view.
You can trigger a release changes operation for multiple selected elements.

A release changes operation can have the following effects:

The change status of the released elements is affected by a successful release. That means that all released elements have the change status Unchanged after a successful release.
The visibility of elements is not affected by a successful release. That means hat in the branch the same Solution Documentation content is visible after a successful release.
The solution documentation content in the parent branch is updated. That means that all released elements are visible in the parent branch after the release.
An attempt to perform a release changes operation fails if the release is not allowed. That means for a failed release you get an error message and all elements and their change status remain unchanged.

Release of a single Elements

You can release changes per element individually by triggering the release changes operation in the context menu under Element Changes for selected elements which have been changed in the branch and thus have a change status different from Unchanged. All changes of the selected elements are brought into the parent branch.

Release of a Subtree

You can release changes also for entire subtrees by triggering the release changes operation in the context menu under Subtree Changes for selected subtree root elements. All changes of the selected subtrees are brought into the parent branch.

Structure Changes

Changes may not only refer to elements or subtrees but also to further parts of the Solution Documentation, for example:

structure changes like moving of elements, changed target elements of reference elements
changes to external objects, like KW documents or diagrams

A structure changes release operation has the following effects:

An element move affects only the change status of the element moved, the change status of the new parent element is not affected.
The release of a moved element moves the element also in the parent branch.
Changing the target element of a reference element affects only the change status of the reference element, the change status of the new target element is not affected.
The release of a reference element with a changed target changes the target also in the parent branch.

Extended Release Scope

The extended release scope function ensures that no objects can be released if this release would cause broken dependencies in the parent branch. Therefore the release scope is automatically extended to the smallest consistent subset which may be released. The extension is done by the following rules:

The release changes operation extends the selected elements to a release scope containing the required dependencies.
Only the minimal extended scope of the selected elements is released to the parent branch.
The scope is extended by all parent elements with status created.
The scope is extended by all referred original elements with status created.

Release Changes and Production Branch

In a production branch, the release changes operation is not available. There are two situations possible:

A maintenance branch exists for the production branch.
Then the production branch is not changeable directly and can only be opened in read-only mode and no change can be done.
No maintenance branch exists for the production branch.
Then the production branch is changeable directly can be opened in edit mode. All changes are immediately performed in the final production branch. All elements have always the change status Unchanged.

Dealing with Release Conficts

A release changes operation cannot be performed successfully if there are conflicts in the (extended) release scope. Two kinds of conflicts are possible:

maintenance conflicts (change status: Maintenance Conflict)
A maintenance conflict may arise if there are unreleased changes in the maintenance branch. Then for each change to the same element in a sibling child branch of the production branch a maintenance conflict appears. The maintenance conflicts reflect the priority of the maintenance branch over the parallel normal branches. A change in the maintenance branch has preference over parallel changes in normal development branches.

An element with a maintenance conflict cannot be released successfully.
change conflicts (change status: Conflict)
A change conflict arises if after a change is done in a child branch to the parent branch version (the origin parent version) and afterwards the parent branch is also changed to a new parent version. Then there is a change conflict since the origin parent version has been changed before releasing the open conflicting change in a child branch.

An element with a change conflict cannot be released successfully.

Integration of Change Management

If the change management integration has been enabled for a branch in the Solution Administration (on the properties tab for the branch) then the release of changes in the branch is controlled in the change management and cannot be triggered directly in the Solution Documentation. In this case, in the properties tab of the branch the context menu does not provide the release changes operations for element changes and subtree changes.