Workspace Versioning

While process versioning snapshots a single process or module, workspace versioning publishes a version of the whole workspace: creating the workspace version v1.0.0 publishes a v1.0.0 version on every process, module and locale owned by the team. Inherited processes, modules and locales from parent workspaces are never touched.

This gives you a single tag that identifies the full state of the workspace — the base for managing production deployments and rollbacks over the complete set of processes, modules and translations.

Manage workspace versions

Workspace versions live in the Versions tab of the team settings. Publish one by clicking Create version and choosing a tag (for example v1.0.0) and an optional comment.

Publishing walks every owned locale, then every owned module and process:

• An entity that does not have the tag yet gets a new version published — created.
• An entity that already has the exact tag keeps its existing version — skipped.
• If publishing one entity fails, the release continues with the rest and the failure is recorded — failed.

The per-entity outcome is stored in the version’s manifest, visible from the versions list. A release is therefore safe to retry: re-creating the same tag after a partial failure only publishes what is still missing.

Import and translation pinning

When the workspace version is published, every bare module import in the published snapshots is pinned to the new tag, so the versioned code keeps running against the exact module code it was released with:

// Working copy (unchanged)
const { myFunc } = fcode.import("my-module");

// Published v1.0.0 snapshot
const { myFunc } = fcode.import("my-module", { version: "v1.0.0" });

Only imports of modules owned by the workspace are pinned. Imports that already carry a second argument — an options object, or the bare string form ("v0.9.0", or an alias like "production") that predates it — are considered intentional and left untouched, and imports of inherited modules stay bare. The live working copy of your source code is never modified: only the published snapshots are rewritten.

Translations are pinned the same way, in code and in form schemas alike, so a release also freezes the text it shipped with:

// Working copy (unchanged)
fcode.i18n("greetings.hello", { name });

// Published v1.0.0 snapshot
fcode.i18n("greetings.hello", { name }, { version: "v1.0.0" });

A call that already passes options is left untouched. See Internationalization for how a pinned call resolves, including what happens when a locale has no snapshot at that tag.

Deleting a workspace version

Deleting a workspace version cascades: every owned process, module and locale version carrying the tag is deleted, together with the aliases pointing at those versions and the executions and schedules that reference them. Calls pinned to a deleted locale version go back to resolving against the current translations. Use it to clean up a release that should never run again.

Deletion is rejected while a workspace alias still points at the version — delete or re-point the alias first. If some entity version cannot be deleted, the workspace version record is kept and the error lists the remaining entities, so retrying the deletion finishes the job.

Manage workspace aliases

Workspace aliases work like process version aliases, but across the whole workspace: pointing the alias production at v1.0.0 creates or updates the production alias on every owned process and module that has a v1.0.0 version published.

Entities without the target tag (for example a process created after the release) are skipped and reported in the alias manifest; their existing alias, if any, is left untouched.

Since executions, schedules, webhooks and module imports all accept an alias wherever they accept a tag, moving the production alias to another workspace version re-points the whole workspace in one operation — which makes rollbacks a single alias change.

Renaming a workspace alias renames the per-entity aliases in place, so schedules and executions pinned to the alias keep working under the new name. The new name must not be taken by another workspace alias, and if a process or module has a manually created alias with that name, the workspace alias takes ownership of it.

From the CLI

The same operations are available from the CLI:

$ fcode team:versions:create v1.0.0 --comment "First stable release"
$ fcode team:aliases:set production v1.0.0

fcode team:pull also writes the workspace versions and aliases into team.json (read-only fields, for visibility and git history).