release: v0.9.1

[iainmcgin]

Cuts v0.9.1, a patch release driven by #331 — a regression 0.9.0 introduced.

Why now

0.9.0's element-memory bound is sized for untrusted wire input, and buffa's own tooling applied it to the descriptor sets it reads. Codegen started rejecting schemas of a few hundred .proto files with element memory limit exceeded, which is a small enough schema to hit in ordinary use. #332 fixed it; this ships it.

Three other changes ride along: the field-scoped open-enum reflection fix (#321), the view unknown-field pointer change (#329, ~10% faster view decode on payloads carrying no unknown fields), and a documentation correction described below.

The documentation correction

0.9.0's notes said of the element-memory budget that "the owned, view and reflective (DynamicMessage) decoders are all bounded". That is true, and it reads as codec-independent, which it isn't — JSON decoding runs serde_json straight into the generated Deserialize impls, which never receive a DecodeOptions. A message parsed from JSON is bounded by none of the limits that bound the same message parsed from protobuf, and the amplification is nearly as large there: {} is three JSON bytes for the element footprint that costs two on the wire.

Shipping a release about the element-memory bound while the docs overstate which codecs it covers seemed like the wrong pairing, so this adds the scope to DecodeOptions, to with_element_memory_limit, and to the guide — which was also missing with_element_memory_limit from its decode-options table entirely. Actually bounding the JSON path is a real design decision and stays in #330 for 0.10.0. No behaviour changes here.

Version choice

0.9.1 rather than 0.10.0. The only API changes are additive (DescriptorPool::decode_with_options and the new buffa-codegen decode helpers), and #329's restructuring touches a private field with no public signature change — I checked rather than assumed. That matches the convention stated in the changelog header: breaking changes increment the minor, additive changes the patch.

Verification

Ran the CI invocations locally:

• cargo clippy --workspace --all-targets --all-features -- -D warnings — clean
• cargo test --workspace --all-features — 49 suites, 0 failures
• RUSTDOCFLAGS="-D warnings" cargo doc --workspace --all-features --no-deps — clean
• changie merge is idempotent against the committed CHANGELOG.md, so check-changelog passes
• scripts/check-publish-coverage.sh — 8 crates listed and publishable
• markdownlint clean on the changed files; the new guide anchor resolves

The only warning anywhere is the documented editions_2024.proto skip from a protoc older than v30, which is expected outside CI. Conformance was not run locally (no Docker or local runner here); CI covers it.

Reviewer notes

• Consumers must regenerate to get the fix on the generated-code path: descriptor_pool() now scales its decode bound to the bytes embedded in it, and code generated by 0.9.0 keeps the old bound. The buffa-build and plugin fixes apply on rebuild alone. The release notes say this.
• The publish workflow has changed since it last ran successfully. ci: publish every publishable crate, and fail when one is missed #323, ci: repair the duplicate env key that stopped the publish workflow starting #324 and ci: fail the PR that adds an unlisted publishable crate #325 all modified publish-crates.yml after the v0.9.0 tag, so this tag is the first to exercise the current version. ci: repair the duplicate env key that stopped the publish workflow starting #324's bug was a duplicate env: key that made the workflow silently fail to start — worth watching the run rather than assuming it. The lint-workflows actionlint job added in ci: repair the duplicate env key that stopped the publish workflow starting #324 guards that specific class now.

Draft pending review.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}