Versioning & Publishing

The versioning system lets you iterate on your plugin without breaking existing deployments. Each version is independent — its own YAML, parameters, changelog, and vault files.

Creating New Versions

From the plugin editor, clone the current version to create a new one. The new version starts as unpublished and inherits the YAML, parameters, and vault files from the source version.

This lets you make changes safely — scenarios using the previous published version continue to work while you develop the next one.

Publishing a Version

When your version is tested and ready:

1. Click Publish in the plugin editor toolbar
2. Add a changelog entry describing what changed

Unpublished versions are only visible to editors (you and your team, depending on edit permissions). Published versions become available for use based on your Use permission setting.

Scenarios that already reference a published version keep using it. Publishing a new version doesn’t automatically upgrade existing deployments — scenario architects choose when to upgrade.

Cloning

Two types of cloning:

Clone Within Plugin (New Version)

Creates a new version of the same plugin. Use this for iterating — v1 stays stable while you develop v2.

Clone to New Plugin (Fork)

Creates an entirely separate plugin with its own name, permissions, and version history. The YAML, parameters, and vault files are copied over.

Use this when you want to build something new based on an existing plugin’s foundation. For example, cloning the “Create Root DC” plugin to create a “Create Child DC” variant.

In both cases, vault files are automatically cloned with the version.

Version History

Every time you save your YAML, the system creates a history entry. Use the inline diff editor to compare any two versions side-by-side — useful for tracking what changed or reverting to a previous approach.