Lifecycle: Versions & Deployment

Editing a resource in a draft revision never touches the running application. The revision’s lifecycle decides when your work goes live, when it is locked, and how it travels to another environment. All the buttons below live on the revision form (Projects & Resources).

Revision status

Draft

The working state — add, edit and delete resources freely. Nothing is visible in the application.

Activated

Deployed. The revision’s resources are live in the application.

Published

Locked. A published revision is an immutable snapshot; further changes go into a new revision.

Activating a revision

To put your work live, click the Activate (rocket) button on the revision.

Every resource is written to the application’s metadata, exactly as if a module had shipped it. Views, models, actions, menus, selections, queries, workflows and translations all take effect immediately.

The normal building rhythm is a loop: edit in the designers → Activate → check the result in the application → edit again.

Workflows are the exception to editing an activated revision. Saving one never writes it to the application; the designer’s own Deploy button does, one workflow at a time (Workflow designer). Every other resource type in an activated revision goes live as you save it.
Only one revision — across all projects — is active at a time. Activating a revision deactivates any other active one.

Deactivating

The Deactivate button withdraws the revision: all its deployed metadata is removed and the revision returns to draft (a published revision stays published — only its deployment is withdrawn).

Deactivating removes the customizations from the live application. Data of custom models is not deleted, but it becomes inaccessible until a revision defining those models is activated again. Be deliberate with this on a production system.

Publishing

When a state is worth keeping, click Publish on the activated revision.

Publishing locks the revision permanently: its resources become read-only and the revision joins the project’s history. To keep working, create a new revision.

Creating new revisions

Revisions are numbered major.minor.patch. The project form offers three buttons:

Create a patch version

The everyday button. Copies the latest published revision into a new draft with the patch number incremented — publish what works, patch to continue.

Create a minor version

Starts major.(minor+1).x for incremental feature work.

Create a major version

Starts (major+1).0.x for milestone changes.

Each new revision is a full copy of its predecessor’s resources, so editing it never disturbs the published one.

Create a patch version refuses to run while the latest revision is still unpublished — publish (or delete) that revision first.

Exporting

Two more buttons on the revision hand your work to other environments:

Export

Downloads the revision as an app package — the resource definitions in a portable form, ready to import into another instance or keep under version control. For continuous sync to git, see Build Jobs & Repositories.

Build

Submits a build job that assembles a deployable WAR of the application including the project. Also required for revisions containing compiled JPA entities. Follow progress under Studio → Build Jobs.