Development Releasing

Releasing

Cutting a release of the Platemaker GUI.

Where the version lives

CMakeLists.txt in the GUI project root is the single source of truth. Everything else derives from it: PLATEMAKER_GUI_VERSION that the About dialog reports, and MyAppVersion that the installer script stamps into Platemaker-<version>-Setup.exe.

Bump it there and nowhere else.

When to bump

The working habit is to bump the patch number immediately after a release, in the first commit that follows it, so the version in the repository is always ahead of the last published one rather than equal to it.

If a change is more than a fix — a contract change, or anything that alters what the application does rather than how well it does it — bump the minor (or major) at the point the change lands, rather than waiting for release time.

The reasoning behind a given bump is recorded in the library's docs/TODO.md under Releases, which tracks both projects' numbers together.

Versioning against the library

The GUI pins a minimum libplatemaker version, and since 1.1.0 that minimum is enforced at configure time rather than surfacing later as compile errors.

The consequence for releasing: the library must be published first. The GUI's pinned version also builds the FetchContent download URL, so until that library release exists on GitHub Releases, anyone configuring without a local LIBPLATEMAKER_DIR gets a 404.

Order is therefore: tag and upload the library, then the GUI.

→ Building

The changelog

docs/CHANGELOG.md, organised as Added / Changed / Fixed, written from the user's point of view rather than the commit's — what changed for someone using the application, and why it matters.

Publishing a release (automated)

Releasing is driven by a GitHub Actions workflow (.github/workflows/release.yml). Pushing a bare version tag (1.4.0 — no v prefix; that is the tag pattern *.*.*) builds and publishes the release end to end on a Windows runner:

1. Builds the Windows installer (Qt 6.11.1 MinGW + Inno Setup), pulling libplatemaker from its own GitHub Release.
2. Attaches a build-provenance attestation.
3. Publishes a GitHub Release with Platemaker-<version>-Setup.exe and its SHA256SUMS.txt.
4. Scans the installer on VirusTotal.

Running the workflow manually (workflow_dispatch) does a validation build and uploads the installer as a run artifact, but publishes no Release — the publish/scan steps are tag-only.

Pushing tags and running the workflow are repo-owner actions, so this is not something a contributor performs. It is documented here as the release mechanism.

Order still holds: the library must be released first (see Versioning against the library), or the GUI build's libplatemaker download 404s.

Building the installer locally

For a local build without the workflow:

cmake --build build/<kit-name> --target installer

Produces Platemaker-<version>-Setup.exe in installer-output/. It requires Inno Setup, and the script (Platemaker.iss) bundles the executable, platemaker.dll, the libvips runtime, Qt and its plugins — the installed application has no external dependencies.

Installer behaviour, for reference: installs to Program Files, requires administrator rights, shows the GPL-3.0 licence for acceptance, offers an optional desktop shortcut, and closes a running Platemaker.exe before replacing it.

Signing

The installer is not code-signed, so Windows shows a SmartScreen warning on first run. This is a deliberate deferral rather than an oversight: certificates cost money, and the intention is that Platemaker pays for its own signature if it ever earns anything.

Documented for users in Installation.

Testing before release

There are no automated GUI tests, so this step is entirely manual.

Afterwards

• Bump the patch version in CMakeLists.txt
• Update the version block on the wiki's Home page and the footer

---

See also: Building · Contributing · Development