Version management

Each workflow lives in two complementary worlds: a Main version, always alive and ideal for iterating fast, and numbered versions, frozen as soon as they are deployed, which guarantee reproducibility. Understanding this distinction is the key to developing without friction while delivering safely.

Main version and numbered versions: the right reflex

Comparison	Main version	Numbered versions (e.g. 1.2.0)
Role	Permanent development line	Named, traceable snapshots
Evolution	Always modifiable, even if deployed elsewhere	After deployment: no more modification of the graph or the logic
Possible adjustments	Everything can change	Only the tracing level (the other parameters remain frozen)
Production	Not deployable in a production environment	This is the format adapted to production deployment

In practice: you develop and test on Main (short loop, immediate changes); you freeze a semver version when the behavior suits you, then you deploy this version to prod — not Main.

The Main version: always in motion

Main is the continuous version: it reflects the current state of the workflow as you edit it. It is not a frozen snapshot.

• Ideal for developing: you modify the workflow, you save, you test again — without creating a version at each attempt.
• Deployed or not, it stays editable: even if Main is deployed on a non-production environment (dev, staging, etc.), you can keep modifying it. The next executions will take these changes into account: perfect for instantly testing an idea or fixing a detail.
• Immediate effect: no "create a version → redeploy" cycle as long as you stay on environments where Main is allowed.

Main and production

The Main version cannot be deployed to production. For any production environment, you must go through a numbered version (semver fork), then deploy it. This is what protects prod against uncontrolled changes on an always-moving line.

Numbered versions: semver and immutability

When you create a version (fork with a number), you produce a stable identifier (1.0.0, 1.1.0, etc.). This version carries its changelog and its history.

Important rule: as soon as a numbered version is deployed, it becomes immutable for everything that defines the behavior of the workflow (nodes, connections, business logic, etc.). You can no longer "touch up" this version to evolve it: you must create a new version (new number).

Only exception: you can still adjust the tracing level on an already deployed version — useful to diagnose without republishing a release. The available modes (Complete, Standard, Performance) and the duration of the Complete mode are described in Tracing modes.

Version format (SemVer)

Use Semantic Versioning so that everyone understands the impact of a release:

• MAJOR: breaking changes (e.g. 2.0.0)
• MINOR: backward-compatible new features (e.g. 1.1.0)
• PATCH: fixes without expected functional API change (e.g. 1.0.1)

Pre-release versions (suffixes)

A suffix can be added to mark a non-stable version, in the MAJOR.MINOR.PATCH-<label>.<number> form:

• 1.0.0-beta.0, 1.1.0-beta.1, 2.0.0-rc.1…

• The label is free (beta, rc, alpha, …).

• The following number increments at each new version with the same label (beta.0 → beta.1 → beta.2).

A suffixed version remains a numbered version: as soon as it is deployed, it is immutable (except the tracing level).

Create a version (fork)

Ecosystem materializes a new numbered version by a fork of the current workflow.

From the editor

1. Work on your workflow (often from the Main version once the behavior is stabilized).
2. Click Fork (or Branch).
3. Fill in the form:

Field	Required?	Description
Version	Yes	SemVer number (1.0.0, 1.1.0, 2.0.0, …); free suffix possible for pre-versions (1.0.0-beta.0).
Changelog	Strongly recommended	Summary of the changes delivered with this version (changelog on screen).

4. Validate with Save.

The new version appears in the history; you will be able to deploy it on the desired environment (reminder: the trigger must be deployed on the same environment).

Version statuses

Three status labels come up in the interface:

Status	Meaning
Draft	The workflow is being edited (unfrozen Main version) — default state after creation.
Main	The working version, always modifiable — see The Main version: always in motion.
Deployed	The version is (or was) deployed on at least one environment. For a deployed numbered version, the functional content is frozen (except the tracing level).

Manage versions in the interface

Version list

1. Open the workflow record.
2. Go to the Versions tab.
3. The list shows in particular: number, creation date, changelog, status.

Consult a version

1. Versions tab.
2. Click the version row.
3. Visualize the graph as it was for this release.

Compare versions

The version history allows visualizing the changes between two versions:

1. Versions tab.
2. Select two versions to compare (or use the comparison mode).
3. The graph differences (added, modified, deleted nodes, connections) are highlighted.

Understand the history

Each row of the version history displays the version number, its creation date, its changelog (entered at fork) and its status. To easily find a version:

• Identify the deployed versions (associated with an environment) — they are flagged in the list.
• Consult the changelog of a version to know what it contains without opening the graph.
• Use the version comparison to identify precisely what changed between two deliveries.

Deploy a version

1. Versions tab.
2. Choose the version (in production, a semver version, not Main).
3. Deploy → environment choice → confirmation.

At deployment time, the interface proposes to check the dictionary variables used in the workflow (filled in and correct for the target environment).

For the details of the prerequisites (trigger, environments) and the dictionary variables, see Deploy a workflow.

Next steps

• Deploy a workflow
• Test a workflow
• Tracing modes