Component versions

Each component can have 4 possible versions.

There is always a live version.

If a component is developed or maintained, the stages development and pilot will be available, too.

If special testing or auditing is required, a component can also be labeled as audited.

Why versioning 

Reasons for component versions:

  • The component can be developed and tested without disturbing the default live version 
  • Before updating a live component, the owner can share a preview (pilot version) of the component
  • The audited version can be a separate version that will remain unchanged until the next audit

Apply a different version than "live"

To test the development or pilot version of a component, you can clone the catalog item that the component is in.

In the cloned catalog item, you can specify a version other than live.

You can then create a workspace with this (temporary) catalog item and test if the new component version works as intended.

Development cycle

A component can be developed, tested and published in steps. 

  • Create: Creating a new component will generate a live version.
  • Edit: Editing a component will generate a development version (or if the development version already exists editing will overwrite the development version)
  • Promote to Pilot: The component can be edited until it is ready to be tested. The component can then be promoted to a pilot version
  • Promote to Live: If the component has been tested the component can be promoted to an updated live version
  • (optional) Promote to Audited: If a component has been audited (f.e. pentested), promoting it will generate an audited version


Every component at least has a live version. When you create a new component a live version will be generated.


When editing a live version a development version will be generated (or if the development version already exists editing will overwrite the development version). This means you can develop on a component without issues for the people that use your component in a catalog item.

You can create your own catalog item and select the development version of the component in order to test it.


After you have finished your edits you can promote the development version to a pilot version. This pilot version can be used by catalog item owners to create a separate item in order to test the edits in the component without affecting the users of the catalog item.

Any findings from the tests can be solved in the development version again and the component can be promoted to pilot again. The pilot version itself cannot be edited. When the pilot version is accepted by the catalog item owners it can be promoted to an updated live version.


The audited version can be used by the component owner when they have an audit, for example a penetration test of a catalog item containing this component. This way you can keep the component at the same version in the period that the audit is valid. You can update the live version through the development cycle without touching the audited version.

In the component overview each component that contains an audited version is indicated with an 'Audited' icon. Catalog item owners can easily find and select an audited version.

General component features

Most features of a component can be updated per version. However, some features of managing a component are the same for all versions. This means they can not be edited in the component wizard but should be edited from the component overview via the Action menu .

Owner and support

  • Ownership
  • Support

Deleting a component

When you delete a component all versions of that component will be deleted. It is not possible to delete separate versions. If the deleted component is used in a catalog item the status of that catalog item will go to "broken".

Reset development cycle

Editing and updating a component should improve the component. But sometimes an update has not the desired outcome and you might want to revert the edits.  In the details view of the development version you can use the 'reset development' button on the development tab. This will:

  • generate a new development version, which is a copy of the current live version
  • generate a new pilot version, which also is a copy of the current live version


Deprecate a live version

If a component gets outdated the owner can decide to not maintain it anymore. To inform the component user about this, the owner can choose to add a 'deprecated' label to a live version component. This label can be removed again if needed.

Note: the 'deprecated' status only labels the component and does not change the component properties.

Deprecate an audited version

An audit of a component often will only be valid for a limited period. After this period the component owner might want to inform the user that the quality of the component cannot be guaranteed anymore. The owner can choose to add a 'deprecated' label to an audited version. This label can be removed again if needed, f.e. when the component has been updated and audited again.

Activate / disable

Each component version can be activated and disabled. The owner can choose 'Activate' or 'Disable' from the details view of the corresponding version.


If you want to start developing on a component which you do not have developer rights for, cloning it is a solution. Even if you have developer rights, you might need a non-identical twin of the component, for instance just to change a few parameters.

You can clone a component via the details view: extend the component's display by clicking the downward arrow on the left side of the component overview (or click elsewhere on the row in the overview). The clone button is on the lower left of the extended component display.

Clicking the clone button will create your own instance of the component and take you to its editing wizard to make the changes you need. 

Please note that you can only clone components with a publicly available repository for the script. Unless you change the script source, also your new component will remain dependent on the given repository.

Also note that it does not make sense to clone components that are run before the SRC-external component. They will not inherit the required properties to run before SRC-external.

Release notes

Every time you edit or promote a component from one version to another you will be prompted to write release notes. 

Although a note is optional, it is good practice to keep track of changes that are done to a component during a development cycle.

Adding or cloning a component generates an automatic release note with a timestamp. Same holds for leaving a note empty during promoting a component: it will capture a timestamp of the moment of promotion. 

Automatic note will also appear when the owner of a component or support information is changed.

When promoting from development to pilot version, all development notes are listed (plus the last note of pilot version if it has not been promoted to live yet). This will guide you to write a good summary based on all individual changes.

When promoting from pilot to live version, the last note describing the transition from development to pilot is adopted.

Resetting the development cycle also resets the release notes.

When promoting to the audited version, notes about the audit process are optional.

Promoting one version of a component to another can also happen without actual changes to a component but only with changes captured in a new note. This can be used to clarify previous notes or to capture changes that were made to a component outside of the wizard (the code managed with git for example). 

  • No labels