Node.js 26 is required for the release scripts, which run TypeScript through Node built-in type stripping.
nightcrow uses a fork-to-upstream release flow. origin is the fork used for PR heads, upstream/dev is the development line, and upstream/main is the official release line for code0xff/nightcrow.
The release series is deliberately fixed at 0.1.x. The tool reads .github/release-policy.json, checks the root package, recovery plugin, Cargo lock entries, and viewer package/lock versions, and prints a dry-run by default:
node scripts/prepare-release.ts
node scripts/prepare-release.ts --jsonOn a clean branch, use --execute to update all six version entries. The application version is written once, in the root manifest's [workspace.package]; every crate inherits it, so the crates under plugins/ have no version of their own to bump. The lockfile still records each crate separately. The tool reads tags from the authoritative code0xff/nightcrow remote (or the official HTTPS URL when that remote is not configured), never from a stale local tag list; tag-network or authentication failures stop the command. The first no-tag release is 0.1.1; after that, the next version is exactly one patch above the highest official v0.1.* tag. An explicit --version is accepted only when it matches that calculated value.
node scripts/prepare-release.ts --execute
git add Cargo.toml Cargo.lock viewer-ui/package.json viewer-ui/package-lock.json
git commit -m "chore: prepare release v0.1.2"
git push origin release/v0.1.2Open that branch as a PR from the fork to code0xff/nightcrow:dev. Do not edit versions by hand, skip a patch, or raise major/minor without an explicit maintainer decision.
Use the local Unix gate for early feedback when changing Unix-specific behavior, and use hosted checks as the merge and release authority. The local gate is optional and covers only the Rust gates in Linux; it does not validate all release targets or the viewer.
| Stage | Local verification on Windows | Hosted verification required |
|---|---|---|
Pull request to dev or main |
Before pushing Unix-specific changes (cfg(unix), platform seams, PTY, signals, or file permissions), docker compose run --rm unix-gate is recommended. It is also available for quick feedback during other Rust work. |
The pull request CI must pass. Its Ubuntu and macOS jobs are the authoritative Unix checks; the Windows, Rustfmt, and viewer jobs must pass as well. |
Release on official main |
The local gate may provide early feedback, but it is not a release requirement and cannot replace hosted checks. | Require main CI and the release workflow to pass for the official commit. The release workflow must complete its quality checks and all four platform builds and tests before publishing. |
When reporting verification, name any applicable checks that were not run. The compose gate uses rust:latest, while CI selects the moving stable channel; because the repository has no rust-toolchain.toml, the local container is not guaranteed to use the exact CI compiler version.
After the preparation PR is merged into upstream/dev and its checks are green, open a separate promotion PR from dev to main. The release workflow runs only when a commit reaches main in the official repository; a push to a fork never publishes anything.
The workflow verifies the package policy, runs the workspace tests on each release runner, and builds these exact assets:
| Platform | Asset |
|---|---|
| Linux x86_64 | nightcrow-x86_64-unknown-linux-gnu |
| Windows x86_64 | nightcrow-x86_64-pc-windows-msvc.exe |
| macOS x86_64 | nightcrow-x86_64-apple-darwin |
| macOS arm64 | nightcrow-aarch64-apple-darwin |
Only after all builds and tests pass does it create v0.1.x, generate SHA256SUMS, and create a draft GitHub Release. The tag must point at the exact main commit. A retry resumes a draft only by uploading missing assets; every existing asset must match the local SHA-256 digest and size. Once the set is complete, the draft is published. A published Release must already have exactly the four assets plus SHA256SUMS; mismatches are hard failures and published assets are never overwritten.
The no-argument updater installs the latest stable binary from the official GitHub Release. It does not install from a mutable branch:
nightcrow update
nightcrow update --version 0.1.1 # install a prior stable releaseDevelopment and advanced source installs remain explicit:
nightcrow update --path . # local checkout; cargo install --path
nightcrow update --git URL # named source repository; cargo install --gitRestart the daemon after an update so the running session uses the new binary. Release binaries are the supported user path; local/source installs are for development and diagnosis.
The upstream administrator should protect dev and main, require the CI checks, disallow force-push and deletion, and protect v0.1.* tags from update/deletion. Enable immutable Releases when available. The workflow itself still checks repository identity, branch, version series, exact tag progression, SHA, and asset names, so a copied workflow cannot publish from the fork.