Release workflow

Protected downloads, stable updates, and rollback before public release.

Sightlock will publish Windows installers through a protected account gate. The public download stays closed until code signing, checksums, release manifest, update channel, and rollback proof are complete.

Release channels

Beta: early access for Oliver-approved testers and pilot customers. Builds can change quickly and may include explicit feedback asks.
Stable: signed builds intended for paying customers after final release proof passes.
Internal: unpublished QA builds for app development and regression testing. These must never be linked from the live download page.

Protected download rule

The live download button must require account sign-in and entitlement. Public marketing pages can describe the installer, but direct installer access should remain behind the account licence, release channel, and signed manifest checks.

Installer manifest

Every release should have a manifest entry that can be checked before the download opens. The manifest is the public truth for version, channel, file name, size, SHA256, signing state, and rollback target.

Stable channel: Latest paid-customer release after final proof
Beta channel: Tester release for approved early customers
Checksum: SHA256 recorded beside every installer and blockmap
Signing: Windows code-signing certificate required before public stable release
Rollback: Previous stable installer remains available internally until the next release proves clean

Never overwrite a live installer in place

Build a new versioned installer filename, never reuse the old public file path.
Generate and record SHA256 checksums for installer and blockmap.
Run app release checks, website checks, and download-gate checks against the staged manifest.
Publish the new artifact to the release store as a new object.
Update the manifest to point stable or beta at the new version only after proof passes.
Keep the prior stable installer available as rollback, but do not advertise it to new customers.

Rollback procedure

If a stable release breaks activation, loading, export, map rendering, or updater behaviour, the manifest should be switched back to the previous stable version. Customers should not be given a half-patched replacement at the same URL.

Freeze the broken channel.
Switch manifest stable target to the previous signed build.
Keep a clear incident note in the owner guide.
Publish a fixed version under a new version number.

Code-signing plan

Before the app is public, Sightlock needs a Windows code-signing certificate, signed installer proof, hash proof, and SmartScreen-friendly release history. Until then, the live site should clearly stay in launch access / trial preparation mode.

View protected download page

Release checklist

Check	Required before stable
Production build	Release preflight passes and dev-only flags are not present in the packaged build.
Code signing	Installer is signed and verified on a clean Windows machine.
Manifest	Version, channel, hash, public URL, rollback target, and release notes are written.
Download gate	Unauthenticated users are blocked; entitled trial/paid users can download the correct channel.
Rollback	Previous stable version remains recoverable without overwriting the live installer path.