Skip to main content

Manage Configuration Versions

In some cases, one may wish to maintain a version history for a configuration. E.g., one may wish to maintain historical snapshot version of a configuration of model versions for historical analysis. In addition, one may wish to perform what-if analysis by placing the latest, but not approved, version of the models in a new (and unpublished) version of that configuration.

As with models, these configuration versions are individual objects within the Repository and represent the configuration of the models at a specific point in time.

The Administrator may manage any number of Configuration versions.

Additionally, when one sets a version of a configuration to Published status, it is then presented by default in the UI. I.e., one is really designating a specific version of that configuration as the published version. This means that one may publish a precise collection of model versions.

In all cases, the metadata explorer UI only shows the published version of a configuration, which is simply seen as the configuration.

Information note

While many models in the repository (e.g., models, glossaries, etc.) may have multiple versions, semantic mappings, along with data mappings, do not version. In this way, one does not need to maintain separate versions by version of configuration.

Did this page help you?

If you find any issues with this page or its content – a typo, a missing step, or a technical error – please let us know!