Changes touching this path
- the install page names v0.4.23 now that the artifacts and the detector have landed, which is the condition the constant own comment states: RELEASE_TAG is deliberately not moved by a release cut because it names what dl.millerbyte.com can serve rather than what the workspace is versioned at, and v0.4.23 reached the public bucket in one finalize pass shipping three of five triples with the two darwin ones carried forward on the signed manifest platform_pins, after which the published detector installed it anonymously through all four surfaces and read back loot 0.4.23 exactly. DARWIN_CARRY_TAG is deliberately left at v0.4.14 because the macOS rows are served by that carried pin and not by this tag, so following the tag here would point both rows at a 404, which is the one failure the per-row override exists to prevent; an exhaustive search of the tree finds no other occurrence of 0.4.22 outside this constant, so nothing historical had to be weighed and left standing. the bump is verified rather than asserted, release-pin.net.test.ts running live against the CDN rather than returning early and confirming the published sha256.sum lists each non-carried row asset. the site gate is green from the lane (669 passed and 62 skipped over 61 files, the seven skipped being the pg suites with no test URLs) and the byte budget refused nothing and recorded nothing, all 62 surfaces under ceiling, with privacy reading 592 bytes over its recorded figure and 901 of headroom, a figure the cut already measured and not this change own. no migration, no wire or format byte moves and no host behaviour moves, but the published install page changes, so this owes a site deploy. the workspace suite is green (4140 passed over 132 binaries, 8 ignored) (#2221)
3604a623 · dbf3dbe6…
Renames are not followed. loot's tree maps a path to an address, so a rename is a delete and an add. This list is the history of the name, not of the bytes.