Release process

The selected workflow builds artifacts when a GitHub Release is published.

Before creating a release

Confirm version metadata

The release workflow derives the shipping bundle version from the release tag. These files retain development defaults:

• package.json
• src-tauri/Cargo.toml
• src-tauri/tauri.conf.json

Verify that the release tag is a valid application version, then check the generated bundle name and runtime metadata after the build.

Run all quality gates

npm run check
cargo fmt --manifest-path src-tauri/Cargo.toml --check
cargo clippy --locked --manifest-path src-tauri/Cargo.toml --all-targets -- -D warnings
cargo test --locked --manifest-path src-tauri/Cargo.toml
.venv/bin/python -m pytest tests/python/ -q

Also perform the manual lifecycle and persistence checks in Testing and quality.

Build locally when changing packaging

npm run build:app

This script sets CI=true so DMG creation skips Finder customization that can hang outside an interactive GUI session.

Create the GitHub Release

The workflow listens for:

on:
  release:
    types: [published]

Creating the release starts two independent matrix jobs:

Target	Artifact architecture suffix
aarch64-apple-darwin	aarch64
x86_64-apple-darwin	x86_64

The workflow checks out the release ref, installs the target Rust toolchain and Node version, runs npm ci, installs the pinned Tauri CLI, and runs:

cargo tauri build --target <target-triple> --config '{"version":"<tag-without-v>"}'

Artifact naming

The workflow removes a leading v from the tag and renames found bundles:

Molt_<version>_<arch>.dmg

Each matrix job requires exactly one DMG, renames it to this form, and uploads it to the same GitHub Release with overwrite enabled.

Verify the published release

For both architectures:

1. Confirm the workflow completed successfully.
2. Confirm the artifact name contains the intended version and architecture.
3. Record SHA-256 digests.
4. Mount the DMG and install the app.
5. Verify the app launches on matching hardware or a representative runner.
6. Run a cell and relaunch to test source persistence.
7. Confirm the bundled kernel_server.py and application icon resolve.
8. Confirm no development URL or debug behavior remains.
9. Confirm all kernels die on quit.

Signing and notarization

The current release workflow contains no signing-certificate, hardened-runtime, or Apple notarization steps. Public release notes and installation documentation must continue to disclose Gatekeeper behavior until those steps are implemented and verified.

Stable-release metadata

The documentation template treats a GitHub Release as stable when both draft and prerelease are false, regardless of tag text. Mark development releases as prereleases so they do not become the canonical source for molt-docs.

Synchronize documentation

After publishing a qualifying stable release:

1. Resolve its exact tag and commit.
2. Compare implementation, tests, manifests, and release notes with the prior documented source.
3. Update all affected molt-docs pages and docs-source.json together.
4. Run the documentation repository’s formatting and validation commands.
5. Review the Cloudflare preview before merging.