Publishing Branches

Publishing a branch creates a named, read-only snapshot of the application at that point in time. Publishing does the following:

• Creates a new version with a semantic version number (for example, v1.2.0).
• Makes the version read-only.
• Optionally sets the new version as the default and deletes the source branch.

Published versions can be promoted to other environments and set as the default version that end-users see. After publishing, the platform navigates to the module builder in the new version's context.

Publish a Branch

To publish a branch:

1. In the module toolbar, click the checkout pill.

   

2. Hover Versioned Actions, then select Manage Versions.

3. On the branch to publish, select (ellipsis) > Publish.... The Publish dialog opens for that branch.

4. If the dialog displays a dependency warning, resolve all draft dependencies before continuing. See Dependency Check below.

5. If a previous version exists, choose an Update Type:

   • Major: Significant new functionality or breaking changes.
   • Minor: Small improvements that do not break existing functionality.
   • Patch: Bug fixes or minor corrections.
   • Custom: Enter any version number manually.

   The version number field fills automatically for Major, Minor, and Patch. For Custom or first-time publishing, enter a version number in the format 1.0.0.

6. Optionally, enter a Version Name to give the version a descriptive label (50 characters maximum). The name displays beside the version string wherever a version is chosen, so it is worth naming a version for what it delivered.

7. Set the publish options. See Publish Options below.

8. Click Publish.

A confirmation message displays when the version is published successfully.

Publish Options

The following options are available when publishing a branch.

Dependency Check

Before publishing, the platform checks whether any of the application's dependencies are on draft (unpublished) versions. If they are, the dialog displays a "Draft dependencies must be resolved" message with the affected applications listed by name. Publishing is blocked until each listed dependency references a published version.

To resolve this, update each dependency to a published version on the Manage Dependencies page, then return to the publish dialog.

Stale Base Warning

If Make Published Version Default is selected and the branch was created from an older version, the dialog displays a warning: "Branch isn't based on the current default." The current default version has changes the branch does not include. Publishing this branch as the new default replaces the current default with the branch's content.

The stale base warning is informational. It does not block publishing. Use the Compare with active version button in the warning to review the differences before publishing.

Private Smart Components

Publishing a branch updates each Private Smart Component in the published modules to the definition this version uses.

Publishing never changes what the current default version runs. If you publish without selecting Make Published Version Default, and updating a Private Smart Component would change how the current default version behaves, that component keeps its current definition. The default version your end-users see does not change.

After publishing, the IDE displays a warning that names the components that were not updated, and why:

• The default version is still using an older version. It keeps using that version until this version becomes the default.
• It couldn't be updated from this branch. The branch's version of the component can't be applied, so publishing again doesn't change it.

Semantic Versioning

Unqork uses semantic versioning to number published versions. A semantic version number has three parts: Major.Minor.Patch (for example, 2.1.3). Use the following as a guide when selecting an update type:

• Major: Use for architectural changes, significant new functionality, or updates that change how the application behaves for end-users.
• Minor: Use for improvements that add capability while keeping existing functionality intact.
• Patch: Use for bug fixes and small corrections that do not add new functionality.