# 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:

```bash
./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:

```bash
./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.13

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.