Artifact 9c1ddfdf52f29ce5b42f8a7047d50448aee2abc0332382e9356de4afa81fe828:
- File docs/RELEASE-NOTES-0.7.2.md — part of check-in [3555ad55ae] at 2026-10-24 13:39:42 on branch trunk — zit info shows a horizon clone's horizon and history URL; a dropped seed is not asked for again (user: dmestas, size: 3387) [annotate] [blame] [check-ins using]
zit 0.7.2
zit 0.7.2 closes the limit 0.7.1 named: a store no longer keeps a seed
that a peer sends it outside a seed announcement, so it can never serve
one on. The horizon draft states the rule. zit info also shows a
horizon clone's horizon and the origin's history URL.
This release is from trunk. Stores are unchanged from 0.7.1.
A received seed is never stored
A seed is private to the clone that holds it, and an origin sends one
only under a horizon-seed announcement, which a clone keeps outside
its artifact store. 0.7.1 refused a pushed seed, but an artifact of the
same shape arriving on a clone, pull or sync was stored as an ordinary
control artifact. zit never derived tags from it, but it could serve it
to other peers.
Now every receive path drops an artifact that carries the store's seed
label (zit-seed) or a horizon-seed binding card. The test is made on
the artifact's verified content when it is written, whether it arrived
in full or as a delta completed in a later round. A dropped artifact is
not counted among those received. An artifact sent as a delta against a
dropped one is stored in full. A control artifact under another label
and with no binding card is kept as before.
A zit origin writes pushed artifacts through the same path. It already refuses a pushed seed before writing anything, and it drops a pushed delta whose base it lacks, so a seed completed by a later push never reaches it. The check stands behind both.
zit remembers what it dropped, in .zit-cache/dropped-seeds, and
never asks a peer for one of those again. The record is local and is
never synchronized; deleting it costs one re-fetch and a second drop.
zit info names the horizon
In a horizon clone, zit info now shows the horizon, and the history
URL when the origin gave one with zit serve --horizon-url:
horizon: <full hash of C> (descendants, structural)
horizon-url: https://forge.example/api/v1/r/x/history
The clone records the URL from the last reply that said which horizon level it served, so it follows the origin if the URL changes.
The horizon draft
docs/rfcs/draft-fossil-horizon-00.txt states the receive rule in
Section 5.2.3. It also states that a store which keeps a delta whose
base it lacks must not announce or serve that delta while it cannot be
expanded. Appendix C records the change.
Test harness
The Fossil round-trip script stopped the subshell that started zit
serve, not the server, so each run left a server listening. It now
stops the server. Smoke scenarios that start a server on a fresh
loopback port try another port when the first is taken before the
server binds.
Compatibility
Stores are unchanged from 0.7.1, in both directions. A store written by an earlier release may hold a seed-shaped artifact. zit still skips it when deriving, and a peer running 0.7.2 drops it on receipt.
On the wire nothing changes.
Qualification
The release manifest records native qualification against the exact tagged source archive on macOS ARM64, Linux x86-64 and Linux ARM64, using the pinned Zig 0.17.0 toolchain. Publication is gated on unit and end-to-end tests, Git differentials, deterministic simulation, seeded fuzzing, and Fossil interoperability checks on every distributed target.
For the basis of the conformance claim, see the 0.1.0 release notes.