[kixelated]

Sets rind to 0.4.0 and four adapters to their next patch versions by hand, so the pending release publishes what main holds under the right versions.

Why

main holds two breaking changes to rind: the typed CbcIv (moq-dev/rind#530) and agreement keys that keep their public key (moq-dev/rind#529). Both merged while rind/Cargo.toml was hand-set to 0.3.3 and unpublished. A hand-set version is kept as is, so release PR moq-dev/rind#511 proposed rind 0.3.2 to 0.3.3 with both breaks inside it, and nothing in CI refuses that.

#511 also proposed rind-rustls 0.24.0, rind-rcgen 0.15.0, rind-ring 0.18.0, and rind-str0m 0.26.0. An adapter's version begins with its upstream's breaking part, and sh/adapter-versions.sh refuses all four in the merge queue. That check was the only thing keeping #511 from publishing the breaks as a patch.

Changes

• rind 0.3.3 to 0.4.0, and every workspace crate's rind requirement to 0.4.0.
• rind-rustls 0.23.4 and rind-rcgen 0.14.4: each restored its upstream's API, which CONTRIBUTING.md makes a patch release set by hand.
• rind-ring 0.17.4 and rind-str0m 0.25.3: their own APIs did not change. feat(agreement)!: keys keep their public key and algorithm #529 and fix(rcgen)!: KeyPair offers rcgen's KeyPair API #515 touched their internals, and a ! title makes release-plz propose the next breaking version for every crate its commit touches.
• The README's two install snippets name 0.4.

The branch first reverted #530, as first decided, and then undid that revert when the decision changed; its net diff is manifests, Cargo.lock, and the README.

Decisions

Decided with the maintainer on 2026-11-09, in the quest audit (moq-dev/rind#546):

• With only feat(cipher)!: AES-CBC encryption takes a typed CbcIv #530 on main: revert it and release 0.3.3 now.
• Once feat(agreement)!: keys keep their public key and algorithm #529 had merged too: ✅ set rind to 0.4.0 by hand and hold the release until the last of 0.4's three breaking changes, the CPU-check removal, lands (rejected: set 0.4.0 and ship it now, with that removal as 0.5; revert both and release 0.3.3). Reverting would re-create the hazard each time another ! change merged before 0.3.3 published; a hand-set 0.4.0 ends it.

After this merges

• chore: release #511 regenerates. It should propose rind 0.4.0 and each adapter at a patch version; check before merging it.
• Do not merge chore: release #511 until the CPU-check removal is on main and MoQ's PR (moq-dev/moq#8400 plans it) is ready. Until then no adapter fix and no pyrind release publishes.
• moq-dev/rind#516 and moq-dev/rind#519 carry ! on adapters; if release-plz proposes a breaking version for one after they merge, it needs the same hand-set patch.

Public API and wire

No API change beyond what #530 and #529 already merged. This changes the version they publish under: rind 0.4.0, where a consumer on rind = "0.3" is not moved onto them. Each adapter now requires rind 0.4.0. Wire: none.

Caused by

• moq-dev/rind#530 and moq-dev/rind#529 - each merged a breaking rind change while its hand-set 0.3.3 was unpublished
• moq-dev/rind#521 and moq-dev/rind#515 - each restored an adapter's upstream API with ! and no hand-set patch version

Checks

sh/adapter-versions.sh passes and cargo metadata --locked resolves. just check is queued behind a host-wide job on this machine; this stays a draft until it passes.

Models

Size: S
Implementer: Claude Code, claude-fable-5-2, high effort

🤖 Generated with Claude Code

(Written by Claude Fable 5 with high effort)