Releasing

Releasing

Releases are built by .github/workflows/release.yml when a version tag is pushed. It builds Windows (.exe, .msi), macOS Apple Silicon (.dmg) and Linux (.AppImage, .deb, .rpm) installers, names them DocBox-<version>-<os>-<arch>, and puts them in a draft GitHub Release.

Steps

1. On main, set the new version in all three places:

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

   Use a plain x.y.z version: the MSI installer can't take suffixes like -rc1.

2. Merge that through a pull request and wait for CI to pass.

3. Tag the merged commit and push the tag:

   git checkout main && git pull
   git tag -a v0.2.0 -m "DocBox 0.2.0"
   git push origin v0.2.0

4. Wait for the Release workflow (about 20 minutes). It stops early if the tag isn't on main or the version doesn't match all three files.

5. Open the draft on the Releases page, check that all six installers are there, and edit the list of changes.

6. Install it on at least Windows and one other system. Check that the first launch finishes and that one model reads a file.

7. Publish the draft. Installed copies show the update notice from then on.

If something goes wrong

• The workflow failed before the release job: fix it on main, delete the tag (git push origin :refs/tags/v0.2.0 and git tag -d v0.2.0), and tag again.
• The release job failed after creating the draft: delete the draft and re-run the job. The built installers are kept for 7 days.
• A published release is broken: publish a fixed version with a higher number rather than replacing files in place. People may already have downloaded the old files.

Not done yet

• Code signing on Windows and notarization on macOS, so users don't see security warnings.
• Linux ARM and Windows ARM builds.