The reader list in COMPATIBILITY.md is the declared support window, but the gates do not cover it evenly. Two gaps, both currently documented in that file's coverage note rather than enforced:
1. crates.io rows are not compared against pg-compat/Cargo.toml. The window declares crates.io pg-core 0.6.1 0.5.10, but pg-compat/Cargo.toml pins only =0.6.1, so 0.5.10 is a declared reader that no gate ever runs. The npm side does not have this problem: pg-compat-js/test/manifest.test.mjs machine-reads the fenced block and fails when it drifts from readers.mjs. The crates.io rows have no equivalent, so a row can drift from the manifest with nothing noticing — the same silent-green class the gate exists to close.
Fix, in order of preference:
- add a
pg-core-0-5-10 renamed dependency to pg-compat/Cargo.toml (its comment already anticipates "one renamed entry per published pg-core release") and a matching reader entry, then
- add a test that parses the crates.io rows out of
COMPATIBILITY.md and asserts each has a pin, mirroring manifest.test.mjs.
Worth checking first whether 0.5.10 can open the current sample set at all; if it legitimately cannot, the honest fix is removing the row from the window rather than pinning it.
2. The nuget row has no gate. E4A.PostGuard is producer-only (seal via pg-ffi, no unseal path), so a reader gate needs a decrypt capability the SDK does not have. Options: leave it declared-but-ungated with the note that exists today, or cover the .NET seal direction from postguard-e2e instead (its version sweep already drives published NuGet versions — encryption4all/postguard-e2e#21).
Surfaced in review of #267. Part of #251 / #247 (workstream C).
The reader list in
COMPATIBILITY.mdis the declared support window, but the gates do not cover it evenly. Two gaps, both currently documented in that file's coverage note rather than enforced:1. crates.io rows are not compared against
pg-compat/Cargo.toml. The window declarescrates.io pg-core 0.6.1 0.5.10, butpg-compat/Cargo.tomlpins only=0.6.1, so0.5.10is a declared reader that no gate ever runs. The npm side does not have this problem:pg-compat-js/test/manifest.test.mjsmachine-reads the fenced block and fails when it drifts fromreaders.mjs. The crates.io rows have no equivalent, so a row can drift from the manifest with nothing noticing — the same silent-green class the gate exists to close.Fix, in order of preference:
pg-core-0-5-10renamed dependency topg-compat/Cargo.toml(its comment already anticipates "one renamed entry per published pg-core release") and a matching reader entry, thenCOMPATIBILITY.mdand asserts each has a pin, mirroringmanifest.test.mjs.Worth checking first whether 0.5.10 can open the current sample set at all; if it legitimately cannot, the honest fix is removing the row from the window rather than pinning it.
2. The
nugetrow has no gate.E4A.PostGuardis producer-only (seal via pg-ffi, no unseal path), so a reader gate needs a decrypt capability the SDK does not have. Options: leave it declared-but-ungated with the note that exists today, or cover the .NET seal direction from postguard-e2e instead (its version sweep already drives published NuGet versions — encryption4all/postguard-e2e#21).Surfaced in review of #267. Part of #251 / #247 (workstream C).