Release rpi-loader-ota 0.2.0

RELEASING.md

@@ -64,22 +64,36 @@ format.
    `## [<version>] - <YYYY-MM-DD>` heading plus a link reference at the
    bottom. The workflow greps for that date and refuses to publish without
    it.
-2. `make package-ota` on a clean tree.
-3. Merge the PR, then tag and push:
+2. **Raise the CLI's requirement to match**, in the same change:
+   `rpi-loader-ota`'s version in `cli/Cargo.toml`, then a `cargo check` in
+   `cli/` for its lockfile. This is not optional and not a follow-up — a
+   path dependency has to satisfy the version written beside it, so
+   leaving the CLI asking for the old one fails *every* job with
+   `failed to select a version`, not just the packaging one.
+3. `make package-ota` on a clean tree.
+4. Merge the PR, then tag and push:
 
    ```sh
    git checkout main && git pull
    git tag ota-v<version> && git push origin ota-v<version>
    ```
-4. Approve the parked workflow.
+5. Approve the parked workflow.
 
 **The CLI depends on this package, so it has to be published first.**
 `cargo package` on the CLI resolves `rpi-loader-ota` from crates.io — the
 path dependency is stripped when packaging, which is the point of writing
 both a `version` and a `path` — and a version that is not there yet fails
-the CLI's release before it starts. That is also why CI's package job is
-the first thing to go red if this package is ever bumped without being
-released.
+the CLI's release before it starts.
+
+**So `package verifies` is red from step 2 until step 5, and that is the
+expected state rather than a fault.** Once step 2 has raised the CLI's
+requirement, every other job is green and that one job asks crates.io for
+a version this release has not published yet. It cannot be made to pass
+earlier: publishing is what fixes it. Since the ruleset lists it among the
+required checks, merging in step 4 needs `gh pr merge --admin` — the one
+place in either release where a protection is deliberately stepped over,
+and the reason to do the publish immediately rather than leaving `main`
+sitting in that state.
 
 **What counts as breaking:** the Rust API as usual, and the bundle format
 itself. A change to the container's bytes is breaking in a way a semver

cli/Cargo.toml

@@ -30,7 +30,7 @@ serialport = { version = "4.9.0", default-features = false }
 # The bundle container, shared with whatever firmware installs one. The
 # whole point of it being a crate rather than a module here is that the
 # packer and the parser cannot drift apart.
-rpi-loader-ota = { version = "0.1.0", path = "../ota" }
+rpi-loader-ota = { version = "0.2.0", path = "../ota" }
 # Reading `bundle.toml`. `display` is off because nothing here writes TOML.
 serde = { version = "1.0.229", features = ["derive"] }
 toml = { version = "1.1.4", default-features = false, features = ["parse", "serde"] }

ota/CHANGELOG.md

@@ -10,7 +10,7 @@ wire protocol; this is a library, its consumers are firmware projects in
 other repositories, and tying it to that version would bump their
 dependency every time a command-line flag was renamed.
 
-## [Unreleased]
+## [0.2.0] - 2026-09-02
 
 ### Added
 
@@ -87,4 +87,5 @@ First release.
   same way the packer checksummed the entry, and can skip rewriting one
   whose bytes have not changed.
 
+[0.2.0]: https://github.com/joeferner/rpi-loader/releases/tag/ota-v0.2.0
 [0.1.0]: https://github.com/joeferner/rpi-loader/releases/tag/ota-v0.1.0

ota/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "rpi-loader-ota"
-version = "0.1.0"
+version = "0.2.0"
 edition = "2024"
 description = "Over-the-air update bundle format for bare-metal Raspberry Pi firmware — one container, packed on a host and validated on the device"
 license = "MIT OR Apache-2.0"