HydraCache 0.68.0

HydraCache 0.68.0

This release delivers the generated HC/2 client plane. It uses shipped
0.67.0 as its compatibility baseline and follows ADR-0020:
the unavailable 0.67.1 bare-metal evidence campaign remains deferred without
blocking this Rust release or authorizing numerical performance claims.

Candidate scope

• generation-6 protobuf HC/2 with retained generation-5 compatibility;
• a publishable Rust HC/2 client crate plus buildable Java and asyncio Python
  source previews; Java is not deployed to Maven and Python is not uploaded to
  PyPI in this release;
• a narrow HydraCache-owned Java IMap/FencedLock-shaped facade, not Hazelcast
  wire compatibility or a complete Hazelcast API;
• bounded multiplexing, cancellation, listener repair, topology disclosure,
  fenced-session loss, resource/security metrics, and deterministic fault
  replay; and
• off-by-default Redis keyspace-event subscriptions over the shared verified
  client surface, with RESP2 arrays, RESP3 pushes, exact/pattern subscription
  count/retained-byte bounds, tenant fencing, explicit lag disconnect, and no
  arbitrary PUBLISH or durable/cross-daemon delivery claim; and
• namespace-fenced projection of native cache.typed("redis").put(...)
  mutations to Redis set keyspace/keyevent notifications, without merging
  the native and RESP value stores; and
• exact/custom-namespace, RESP3, no-replay, forced-lag recovery, mixed-source
  no-duplicate, AUTH, and authenticated rediss:// hardening for that native
  projection; and
• reproducible crate/JAR/wheel consumption plus cross-SDK conformance.

Evidence required before Rust publication

The candidate must pass client-schema-check, client-conformance --all-sdks,
and client-package-check. W0-W12 must have exact-commit fast and expected-red
canary receipts. The registered hosted admission must then combine green Linux,
pinned Docker interop, and fuzz receipts from one full commit.
release-evidence --release 0.68 --require-ship remains the final fail-closed
Rust release decision and is expected to remain red until those artifacts
exist. The crates.io workflow separately refuses 0.68.0 unless that exact SHA
has a successful HC/2 Hosted Release Admission, publishes the Rust HC/2 client
in dependency order, and retains post-publication consumer evidence.

Deferred client-distribution evidence

Java coordinates remain 0.68.0-alpha.1-SNAPSHOT; Python remains 0.68.0a1.
Their source, generated codecs, package archives, clean consumers, and
cross-language conformance stay in normal CI, but no Maven or PyPI publication
is part of 0.68.0. Promoting either external distribution requires a separately
dispatched four-lane admission from one exact commit: Linux, pinned Docker,
fuzz, and the labelled Ubuntu 24.04 fixed-host lifecycle soak. Shared or hosted
CI does not impersonate that missing receipt.

The 0.67.1 reference-v1 qualification is also still open. Release 0.68.0
contains no authoritative throughput, latency, capacity, sizing, or competitor
comparison claim.

The additive Redis listener must also keep the command rows in
redis_compat_conformance.json, the focused mutation/event tests, and the
normal Rust/MSRV/Docs PR checks green. Its compatibility boundary is documented
in the Redis keyspace event listener contract.

The ordinary native Rust listener API has an independent black-box gate:
cargo test -p hydracache --test native_event_listeners --locked. It freezes
public raw/typed subscription, filtering, callback lifecycle, access opt-in,
and bounded-lag behavior without making a Redis or remote HC/2 wire claim.

See the release closure ledger and
the evidence architecture.