Surfaced while splitting tikv/client-rust PR 550: the cluster floor (§0) is TiKV v8.5.5, and that release predates shared locks entirely. components/txn_types/src/lock.rs has zero occurrences of shared_lock_infos at v8.5.5 (2026-01-15); the feature landed on TiKV master 2026-02-24 and was backported to release-8.5, so v8.5.6 (2026-04-14) is the first release that emits them, and v8.5.7 (2026-07-09) is current.
The consequence is concrete: nothing in tikv/client-rust PR 556 can be exercised end-to-end today. Its refusal path is unreachable against a server that never produces a shared lock, so that PR ships on unit tests alone, and issue #42's last bullet ("a differential scenario once a TiKV version that emits shared locks is pinnable") is blocked on nothing but this pin.
Worth noting the oracle does not have this problem: client-go's integration.yml runs pingcap/tikv:nightly and pingcap/pd:nightly. We should not copy that — a floating tag defeats the reproducibility argument pins.toml makes for digest-pinning. Moving inside the same release family gets the capability without the drift.
Scope:
- Bump
[cluster] in pins.toml and cluster/images.env to v8.5.7, tag+digest as today:
pingcap/pd:v8.5.7@sha256:c388050b6c2585ca168b0bf70ed891396fefa7387a21b326d2d15a0d2b4a4637pingcap/tikv:v8.5.7@sha256:06ab1b315c62351ed7dacb41c360e083a0599363533e974e66850fe846df232e
- Re-run the full gate and re-baseline
ledger.toml if any declared row shifts. A shift is information, not noise: it means a claim was version-sensitive and never said so.
- Decide whether the
upstream-cluster/ config (which mirrors client-rust's CI) tracks this bump or deliberately stays at the upstream floor. These are two different questions and the answer may be "both, separately" — see the companion issue for the upstream proposal.
- Update the README's stated cluster version and gate-verdict header.
Note this changes what "the cluster floor" means for every Phase 2–4 feature that must state its minimum TiKV/PD version (§0). If we run ahead of upstream CI, the harness can prove things upstream CI cannot — which is useful, but the ledger must say which floor a claim was proven against.
Roadmap §0 (cluster floor) / §8 (verification) / Phase 0 — unblocks #42 and the coverage gap in tikv/client-rust PR 556.
Surfaced while splitting tikv/client-rust PR 550: the cluster floor (§0) is TiKV v8.5.5, and that release predates shared locks entirely.
components/txn_types/src/lock.rshas zero occurrences ofshared_lock_infosatv8.5.5(2026-01-15); the feature landed on TiKV master 2026-02-24 and was backported torelease-8.5, sov8.5.6(2026-04-14) is the first release that emits them, andv8.5.7(2026-07-09) is current.The consequence is concrete: nothing in tikv/client-rust PR 556 can be exercised end-to-end today. Its refusal path is unreachable against a server that never produces a shared lock, so that PR ships on unit tests alone, and issue #42's last bullet ("a differential scenario once a TiKV version that emits shared locks is pinnable") is blocked on nothing but this pin.
Worth noting the oracle does not have this problem: client-go's
integration.ymlrunspingcap/tikv:nightlyandpingcap/pd:nightly. We should not copy that — a floating tag defeats the reproducibility argumentpins.tomlmakes for digest-pinning. Moving inside the same release family gets the capability without the drift.Scope:
[cluster]inpins.tomlandcluster/images.envto v8.5.7, tag+digest as today:pingcap/pd:v8.5.7@sha256:c388050b6c2585ca168b0bf70ed891396fefa7387a21b326d2d15a0d2b4a4637pingcap/tikv:v8.5.7@sha256:06ab1b315c62351ed7dacb41c360e083a0599363533e974e66850fe846df232eledger.tomlif any declared row shifts. A shift is information, not noise: it means a claim was version-sensitive and never said so.upstream-cluster/config (which mirrors client-rust's CI) tracks this bump or deliberately stays at the upstream floor. These are two different questions and the answer may be "both, separately" — see the companion issue for the upstream proposal.Note this changes what "the cluster floor" means for every Phase 2–4 feature that must state its minimum TiKV/PD version (§0). If we run ahead of upstream CI, the harness can prove things upstream CI cannot — which is useful, but the ledger must say which floor a claim was proven against.
Roadmap §0 (cluster floor) / §8 (verification) / Phase 0 — unblocks #42 and the coverage gap in tikv/client-rust PR 556.