RustBox/docs/RELEASING.md

Releasing RustBox

1. Update the version in Cargo.toml and the RustBox package entry in Cargo.lock.
2. Confirm UPSTREAM_BASE is the Oxi revision actually consumed by the release.
3. Ensure no TypeScript sources or separate frontend build dependencies are present.
4. Run the release gate and package only after it passes:

./scripts/package-release.sh

package-release.sh runs scripts/build-release.sh first. That gate regenerates the lockfile, runs the static validator, cargo fmt --check, the full cargo test --locked suite, Clippy with -D warnings, and the locked release build. The ZIP and SHA256 are created only after all of those steps succeed.

5. Verify:

./target/release/rustbox --version
RUSTBOX_CONFIG=./config.dev.toml ./target/release/rustbox --check-config

6. Package the repository without target/, .dev/ or .git/.
7. Generate SHA-256 sums for release archives.

Browser asset build

Browser JavaScript source lives in functional modules under src/web/js/, ordered by src/web/js/manifest.txt. build.rs concatenates those modules into the embedded rustbox-ui.js asset during every Cargo build. The repository has no duplicate ui/ snapshot; src/web/ is the only browser UI source.

Updating an existing checkout to 0.2.11

Do not overlay the release with cp * or another command that skips dotfiles. That can retain stale .github, .env.example, or Cargo.lock files.

Use a clean checkout/extraction, or a dotfile-aware copy such as rsync -a / cp -a source/. destination/. The source release intentionally does not ship Cargo.lock; CI and scripts/build-release.sh generate it before running --locked Cargo commands.