Versioning of an Instance

First, it is useful to understand how an instance is versioned if no release management is configured for the associated pattern. In this case, there is only a linear history of the instance metadata for an instance; a commit is created for an instance with each build or explicitly at the push of a button. For this commit, all fields of the instance are stored at the commit time, so that it is always possible to view the state of the instance at a selected commit in retrospect. The commits are chronologically one after the other, there is no concurrent development of the instance as shown in the diagram below (one point per commit).

If you now work in releases, an instance can have different states at the same time in different releases. Also, the commits are no longer in linear succession, but are only sequential within a release. In addition there are branches with which a concurrent development starts and mergers with which two states are brought together again. Such a development of an instance is to be seen in the following diagram. This representation is also called commit graph.

You can see that the instance had first commits in Release R2, then continued development in Release R3, based on the last state in R2. However, there was then a necessary hotfix in Release R2.HF1. This adjustment was then merged back into Release R3, so the fix applies here as well. Somewhat later, a change was made to Release R4.