activev1.0.2Catalog reviewed 2026-09-23

Desktop Application Release Standard

Defines desktop release artifacts, verification, and evidence records.

Applies to: Desktop applications that ship installable or distributable releases, including local-first Windows tools.

Source maturity: reference

Explanation reviewed 2026-10-01. Catalog identity and source review have separate dates.

Read public Markdown

Purpose and applicability

A compiled desktop package can still fail installation, migration or removal. DRS binds the release note, manifest and artifact to separate lifecycle evidence.

Desktop applications that ship installable or distributable releases, including local-first Windows tools.

How it works

Write the release theme, scope and boundaries, build the final package, and reconcile versions and artifact hashes. Plan detection before mutation, migration backups and recovery. Record installer, runtime, migration and release evidence at their own stages.

Outputs are a release manifest, release note, checklist, packaged documentation, artifact hash and evidence folder; trust, migration or withdrawal documents apply where relevant.

In practice

This release-folder sketch and verification-stage matrix distinguish checks that are often incorrectly combined. The matrix’s pending labels are deliberate, and no sample app is declared releasable.

Release folder specimenillustrative · teaching example, not a verification result

Illustrative release layout and migration sequence adapted from the release specification and migration template.

Source: DRS/Desktop Application Release Standard.md

release/
├─ ExampleApp.msix
├─ ExampleApp.manifest.toml
├─ Release-Note.md
├─ Release-Checklist.md
├─ release.hashmanifest.toml
└─ evidence/
   ├─ install-upgrade-remove/
   ├─ runtime/
   └─ migration/

Migration: detect source schema → backup → transform → update marker → verify.
Backup failure: abort. Unsupported newer schema: refuse to open.

Inspect Release folder specimen

Distinct verification stagesillustrative · teaching example, not a verification result

Editorial stage matrix: every row needs its own date, scope and evidence; this is not a completed audit.

Source: DRS/templates/Integrity-Validation-Matrix.md

Stage                 Evidence to record                     State
Build/package         final artifact and build result         pending
Install/upgrade       lifecycle checks and logs               pending
Runtime               launch, persistence, intended behavior pending
Migration             backup, transformed data, recovery      pending
Integrity             exact final artifact and hashes         pending
Release review        aligned docs, gaps, distribution        pending

Inspect Distinct verification stages

Adopt one part

Start with a bounded surface or record. Complete the relevant adopter checks before extending the claim.

Name one release and align its artifact, version, release note and manifest.
Describe one data migration or install lifecycle boundary, including backup and refusal behavior.
Run the relevant stages on the final package and retain dated evidence; keep untested stages visible.

Sources and limits

A hash match does not establish installer behavior or a security audit. Build success does not prove migration, uninstall or runtime persistence. The integrity matrix defines detection and repair; an actual completed matrix needs evidence.

These are reviewed public explanations, not the normative specifications. Suite references are relative to the canonical collection; site/ references identify committed website sources and webserver/ references identify serving configuration. Illustrative examples demonstrate record shape; they do not establish compliance. Suite checks and adopter validation are separate.

DRS/DRS.manifest.toml
DRS/Adoption-Guide.md
DRS/Validation-Checklist.md
DRS/Desktop Application Release Standard.md
DRS/templates/Integrity-Validation-Matrix.md
DRS/templates/Data-Migration-Contract.md

Reviewed manifest facts