All projects, all underlying objects, all basic data and all business rules which have been created in the Designer must be versioned.

Definition: A version corresponds to a validated and stable subset of all modeling projects and/or objects in all workspaces in the Designer repository.

The Designer allows you to create multiple versions of the modeling projects in the repository. Each version you create will allow you to indicate that “as of a certain date, the data or behavior of certain modeling projects will change”.

Moreover, the Configurator will allow you to run multiple versions of the same modeling projects simultaneously. This is particularly important when:

• You are running a Configuration Process at time T~current~ but you would like to see which business rule changes are being applied as of time T~future~. This will allow you to test the impact of the application date on the behavior and result of your configuration.
• You want to re-open a Configuration Process at time T~current~, however the Configuration Process has been created at time T~past~. This will allow you to see how the Configuration Process behaved in the past, although a new version has been issued.

The versioning process is a sequential process, meaning that each version has 0 to 1 versions preceding it and each version has 0 to 1 versions following up on it. This has been illustrated in the following image:

In this image, you can also see a working version.

Definition: A working version corresponds to the current state of the modeling repository, which will be used to issue a future version.

A working version will thus contain all projects and objects which were present in the last produced version, plus the modifications applied to them, minus the objects or projects deleted since then, plus the objects or projects added since then.

The Designer can also apply fixes on a version.

Definition: A fix corresponds to a correction which has been applied on a specific version.

Whereas the Configurator can run multiple versions of the same Configuration Process simultaneously, it cannot do the same for fixes. Indeed, as a fix is being considered as a correction applied to a specific version, the Configurator always runs using the latest fix.

In the above example:

• A fix has been applied to version 1
• 3 fixes have been applied to version 2
• No fixes have been applied to version 3 but a future fix is in progress

The Configurator will be able to run only 3 stable versions:

• Version 1 with fix 1.1 applied
• Version 2 with fix 2.3 applied
• Version 3 (without fix)

The Configurator will be able to run 2 “versions in progress”:

• The working fix for Version 3
• The working version itself (that will later on become Version 4)
  information: Fixes are applied to a specific version, meaning that if N versions contain the same error, N independent fixes will have to be produced.
  Warning: Only versions can ensure a transparent deployment with no risk of affecting current users sessions. A user with a session on a given version will keep working on this same version of model and data until the end of the session. Only new sessions will use the newer version. On the contrary, fixes come with a non transparent deployment scheme that might impact the current user sessions.

  When a new fix is deployed, the data are immediately changed with no guarantee of ordering in the loading of those data nor any guarantee of completeness (only the changes that have been chosen to be part of the fix are in the fix). For example, the removal of a standard item as part of the fix may lead to a software error if a given user of the Catalog is currently browsing a collection loaded initially that still reference this SI, either because the updated collection without the reference is not part of the fix or because the new collection that is part of the fix hasn't been loaded yet.

  Warning: There is a governor limit for the maximum number of versions.

  There's a scheduled clean-up script, that runs on a daily basis, to delete all additional versions surpassing the governor limit.

  For more information on the governor limit please refer to the Governor Limits section.

  Starting with release v12.18(Fix115) all newly created environments will have the clean-up schedule activated by default.

  All environments existing prior to release v12.18(Fix115) will remain as they were previously configured.

  Any change to the Governor Limit or the clean-up schedule needs to be approved by the Cloud Infrastructure team.