Releases

Four so far, on both remotes.

Tag	Carries	Notes
v0.1.0	here-capture-macos-arm64.zip	pre-release. Apple Silicon only
v0.1.1	here-capture-macos-universal.zip	superseded by v0.1.2
v0.1.2	here-capture-macos-universal.zip	the macOS client, complete. Its Windows half does not compile — see below
v0.1.3	here-capture-windows-x64.zip	the first Windows binary. No macOS asset, deliberately

Why the Windows binary is on v0.1.3 and not v0.1.2

The plan was one version carrying both platforms. It could not work: at the v0.1.2 tag, crates/here-indicator/src/windows.rs still imports two things from the modules they had been moved out of, so the Windows half of that tree does not compile and no v0.1.2 Windows binary exists to attach.

Rather than attach a build of a later commit under that tag, v0.1.3 was cut. And v0.1.3 carries no macOS asset for the mirror-image reason: there was no Mac available to build one from that commit, and labelling v0.1.2's bundle as v0.1.3 would be the same error in the other direction. The next release cut from a Mac should carry both.

A tag that cannot produce the binary attached to it is a small lie, and this is not a project that gets to tell small lies about provenance.

Signing, stated precisely

• The macOS bundle is signed ad hoc. Ad hoc means verifiable, not trusted: codesign -dv is happy, Gatekeeper is not. It will still refuse the app after a download.
• The Windows build is not signed at all. Not ad hoc, not EV. SmartScreen will object.

Neither is "signed" in the sense a user means, and modules.signature_ok records false rather than pretending otherwise. An EV certificate on Windows and a Developer ID on macOS are the only fixes, and there are none yet. This is on the app's own first screen too, not just in a document.

Cutting a Windows release

Once .\scripts\verify.ps1 is green:

pnpm -C packages/console-web build
cargo build --release
$out = "dist\here-capture-windows-x64"
New-Item -ItemType Directory -Force $out | Out-Null
Copy-Item target\release\here-*.exe $out
Compress-Archive -Path $out -DestinationPath dist\here-capture-windows-x64.zip -Force

Twelve binaries in one folder, which is the layout the console and the supervisor both expect. Smoke-test the release binaries as a running stack before uploading — every test runs against the debug profile, so a release build is a configuration nothing has exercised.

Cutting a macOS release

./scripts/bundle-macos.sh --universal

--universal is the part that matters: it builds both architectures, lipos each binary, signs ad hoc, and refuses to produce a bundle that does not then verify. Without the flag it builds for the machine it is on, which is what a local check wants and not what a release wants.

Publishing

GitHub has gh:

gh release create v0.1.N --notes-file notes.md dist/here-capture-windows-x64.zip

Forgejo does not. Its API takes the same credential git push already uses — git credential fill, then Basic auth:

• POST /api/v1/repos/{owner}/{repo}/releases with {tag_name, name, body, prerelease}
• POST /api/v1/repos/{owner}/{repo}/releases/{id}/assets?name=... as multipart

In PowerShell 7 the upload is one line: Invoke-RestMethod -Form @{ attachment = Get-Item $zip }.

Push tags to both remotes first, or the release has nothing to attach itself to.