Publish and version packages

Publishing means uploading your Designer automation to Zoan Cloud, where it is saved as a package with a version number. Only after publishing it can you create a process and run it unattended or scheduled.

Every time you publish, a new version of the package is created. Previous versions are preserved: they are never overwritten.

Publish from Designer

1. Open your project in the Designer and verify that it works by running it locally. See Debugging.
2. In the toolbar, click Publish.
3. Indicates the version (see semantic versioning) and, optionally, release notes.
4. Confirm. The Designer packages the project into a .zoan file and uploads it to your tenant.

The package appears in the Packages section of the portal, ready to be associated with a process.

What does a package contain?

A .zoan package is a compressed file with your project. In its root it has a project.json manifest that describes the package:

{
  "name": "Facturación",
  "version": "1.2.0",
  "entry": "playbooks/main.json"
}

Field	What it is
name	Nombre del paquete
version	Semantic version of this post
entry	Main playbook running first

You don’t need to edit this file by hand: the Designer generates it when publishing.

Semantic versioning

The versions follow the MAYOR.MENOR.PARCHE (semantic versioning) format. Each number communicates the change rate compared to the previous version:

Incrementa…	When	Example
PARCHE	Bug fixes, without changing behavior	1.0.0 → 1.0.1
MENOR	New functionality compatible with the previous	1.0.0 → 1.1.0
MAYOR	Changes that modify expected behavior	1.0.0 → 2.0.0

This tells whoever operates the process how risky it is to adopt the version: a PARCHE should be safe; a MAYOR requires validation before.

Historial de versiones

From Packages in the portal you see all the published versions of a package, with their date and notes. This gives you traceability: what changed, when and why.

Good practices

• Never modify an already published version. If you found a bug, publish a new version. A published version is immutable: thus a process pointing to 1.2.0 always executes exactly the same thing.
• Write release notes even if they are brief (“corrects VAT calculation”). Your future self will appreciate it.
• Test locally before publishing, and validate the version in the Test environment before pointing Production to it.
• Go up from PATCH/MINOR/MAJOR depending on the actual change, so the number means something.

Next steps

• Create a process — associate this version with an environment.
• Promote between environments — from Test to Production.