igneum-network/igneum
1
0
Fork 0
Code Issues Pull requests Releases Activity

release-0.3.20 plan: 6b94c823's two gate lines (clean on the checks that bear on the binary), the harness sequencing fixes

Browse source 
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
This commit is contained in:
igneum-labs 2026-10-07 12:10:20 +00:00
parent 3f106ae626
commit 80edb84068
1 changed files with 2 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
docs/plans/release-0.3.20.md
View file

@ -395,3 +395,5 @@ Speculative builds on the candidate from the ship worktree, box only, sequential
**The pin rule now:** candidate b7cc37e7 (8097d600 → 6b94c823 → 6a3432a3 → 09124180 → b7cc37e7), igneum-pow 8c728ca3. No fallback commit on the line (6b94c823 dies on a kept datadir); if b7cc37e7's gates are not green by 15:30 BST, 5899f603 stays live and 0.3.20 ships later on green. New gate before the canary, whatever the pin: the kept-datadir start, the pinned binary on a copy of a standing 0.3.17 box's datadir on a scratch pod, the rewrite line as the pass (the fleet). The node lane's clock: b7cc37e7's build about 14:45 BST, the kept-datadir read about 14:50, digest and ten-minute gates about 15:05, the 12 GB claim line about 14:50 to 15:00 on the 6a3432a3 pod (claim code unchanged). The build-server lane's a/b pairs are void and rebuild on b7cc37e7; the shipper's speculative builds on 6a3432a3 stopped by pid (script 30520 and its child) and restart on b7cc37e7; the vendor worktree now at b7cc37e7. Also: the amended v4 packs were stale in the app tree (igneum-pow's recheck tests read the old program id c120d7963abdcd96 from program.json); proto-cuda/packs-ca3-v4 taken from 8c728ca3 as its own commit; tests rerunning on the box.
**Main (13:1x BST):** the fallback reading stands (b7cc37e7 by 15:30 BST or 5899f603 stays live and 0.3.20 ships later today on green). Three additions: (1) standing rule, every canary runs a wiped and a kept datadir, the kept-datadir start a named gate in every release, in docs/plans/release-rules.md (rule 4) and the miner-reliability register as its own fault class (asked of the reliability lane); (2) the Windows shape: the pinned Windows node once against a copy of PC 2's datadir (PC 2 only) before PC 1 gets the build (asked of the build-server lane, with the pairs moved to b7cc37e7); (3) the 16:00 report stands, but on green earlier the publish goes out on green with the clock time. The fleet has the rule and runs the kept start on the pod copy, then the wipe canary on c18-1, then the kept read on c18-1 before its restart step.
**6b94c823's gates on its own binary (the node lane; the lane's "13:56 to 14:08 UK" = about 12:56 to 13:08 BST):** sha b1b7d47b, string 6b94c823. Digest gate: thirteen fields a89be8a7 on both binaries (compat), the sixteen-field object db9a85f9 refused with the mismatch line; the one FAILED check `n3_has_no_peer` is the refused connection's reconnect in flight at the read (harness fix 36d3efdc: the minimum of five reads). Mixed-version gate, ten minutes on the thirteen-field file: digest b0afb2ee on all five, the 5899f603 hub accepted every block the 6b94c823 node mined (146 new, 246 old, 0 rejected), header versions plain 2, counts equal at 536, 695 and 785 through the clean join via the old hub, the join served by the new node, and the new node's restart; the one FAILED check `no_panic_in_any_node_log` is six "Address already in use" panics in the two old nodes' server threads at start (the gates overlapped on ports 29830/29831; now a 20 s gap). So 8097d600's code is clean on both gates by the checks that bear on the binary; the fallback is still not a pin (N13). From here only b7cc37e7 gets gates, on its own binary when its build lands (about 13:48 BST by the clock), lines about 14:05 BST with sha and string.