Releasing

Releases are driven by git tags; the GitLab CI pipeline does the rest.

Cutting a release

1. Update CHANGELOG.md: move the [Unreleased] notes into a new section headed

   ## [X.Y.Z] - YYYY-MM-DD
   

   The release job extracts exactly that section (matched against the tag) to use as the release notes — the pipeline fails if the tag has no matching, non-empty section, so the changelog cannot be forgotten.

2. Bump the version in Cargo.toml and commit.

3. Tag and push:

   git tag vX.Y.Z
   git push origin vX.Y.Z
   

On a tag

1. The usual gates: cargo fmt --check, cargo clippy --all-targets -- -D warnings, cargo test.
2. Release builds for Linux (x86_64-unknown-linux-gnu) and Windows (x86_64-pc-windows-gnu, cross-compiled with mingw-w64).
3. Both binaries are uploaded to the project’s generic package registry under the tag:
   • blurdetector-linux-x86_64
   • blurdetector-windows-x86_64.exe
4. A GitLab Release is created for the tag, with the changelog section as description and direct download links to both binaries.

Docs deployment

This book deploys independently of releases: the pages CI job builds it with mdBook and publishes it to GitLab Pages on every push to the default branch, so the published documentation always tracks the latest merged state.