diff --git a/FABRIC-3.5.md b/FABRIC-3.5.md index afec2402..49163fdc 100644 --- a/FABRIC-3.5.md +++ b/FABRIC-3.5.md @@ -2760,3 +2760,111 @@ be resurrected from memory. **Every design question is ruled and the release number is set.** What remains is execution, one engine-version call, and the close. + +--- + +## XXIX. Versioning policy closed; the LTS designation deferred with written criteria (2026-09-19) + +Captain Bob proposed a revised scheme — **odd major = LTS, even major = working line; minor = +release; patch = working builds; CI build number appended once CI is exposed** — and asked +directly whether this release deserves an LTS number as "the very first fully production ready +version," inviting disagreement and noting the policy should be closed either way. + +**Policy: closed here. LTS designation: deferred, with the criteria written down rather than +left to judgement.** The reasoning below is the disagreement, stated plainly because it was +asked for. + +### XXIX.1 — Why not LTS at this tag: five findings, not an opinion + +1. **§XIV is open, and was reproduced live after being filed.** "Concurrent WIREBIND attach + detection gap — found live, **NOT fixed**, flagged for later" (2026-09-11). §XXXI then + caught it again on the post-Stage-4 rerun: near-simultaneous thumbdrive attach meant **6 of + 9 identities silently never triggered `WIREBIND: attached` at all**, with QMP + `query-block` confirming every device was genuinely present. That is the **identity-attach + path** — how humans get into the system — failing silently and reproducibly. It is not a + corner case, and "silently" is the part that disqualifies it. +2. **It has never booted on real hardware.** That is `FABRIC-3.md`'s entire declared topic, and + the roadmap reserves `v2.2.0` (amd64 bare-metal) and `v2.5.0` (hardware release) for it. + "Production ready" invites the question *production on what?* +3. **ACL Phase 8 is open** — PKI / thumbdrive, Ed25519 challenge-response, user minting by + Zuse: "⬜ **This is the open item — pick up here next**" (`.claude/CLAUDE.md`). That is the + last mile of the security story, and the security story is much of the production claim. +4. **At tag time this reshuffle is brand-new code.** Kernel-Hermes is greenfield C (§XIV.1), + Hestia is a new VM, `BIRTH` is newly general, the latch is new. **LTS normally means + soaked — years of support promised on something proven.** Declaring it at the moment of a + structural rewrite inverts the word. The reshuffle is an excellent reason to tag; it is a + poor reason to call the result long-term-stable. +5. **§XXV.4: formal coverage likely decreases at this tag**, as messaging moves from modelled + FORTH to file-scope C statics. For the audience an LTS label is aimed at — licensees, + SSRN, patent support — the proof story is load-bearing, and this is the wrong moment to + claim maximum stability while the verified boundary contracts. + +**And the precedent is this project's own.** `FABRIC-3.md` §I.2 rolled `LITHOS_VERSION` *back* +from 2.0.1 because the label "got ahead of the real state." **"First fully production ready" is +a far larger claim than `2.0.1` was.** The same instinct that caught that one should catch this. + +### XXIX.2 — The constructive form: make LTS a test, not a judgement + +This document has twice turned a judgement into a structural fact and got a better answer both +times (§XV.2's death, §XXVII's empty floor). Same move here. **Proposed LTS criteria, to be +ratified as part of the policy:** + +A tag may take an **odd (LTS) major** only when **all** hold: + +- **Real-hardware boot demonstrated** on at least the amd64 reference board, with logs + committed as audit artifacts (the existing acceptance standard, extended off QEMU). +- **No known-reproducible silent-failure defect open** — §XIV's class specifically: a failure + that produces no error and is caught only by inspection. +- **ACL Phase 8 closed**, or its absence explicitly scoped out of the LTS claim in writing. +- **The `proof/` boundary restated and not contracted** relative to the prior LTS (§XXV.3). +- **A soak**: the architecture unchanged for at least one full release cycle before the LTS + tag — LTS follows stability, never announces it. + +Then **the first tag meeting them takes the odd major**, and nobody has to decide whether it +feels ready. + +**So: `2.1.0` stands as ruled (§XXVIII) — even major, working line, correct under both the old +and new schemes.** LTS is not refused, only sequenced. + +### XXIX.3 — Three conflicts in the new scheme, to resolve while closing it + +1. **The minor position is already taken, and by a live plan.** The current policy uses *minor* + for QEMU-vs-hardware (`X.0.0` = QEMU release, `X.5.0` = hardware bare-metal release), and + **`v2.5.0` is already on the roadmap**. The new scheme wants minor = "release version." + Both readings cannot hold. **Adopting the new scheme retires `X.5.0` semantics and must say + so explicitly**, or `v2.5.0` becomes ambiguous the day it is cut. +2. **Odd/even major collides with "major = breaking change."** Binding the major to LTS-ness + means a breaking change inside the working line cannot be expressed without also flipping + LTS status, and an LTS line cannot take a breaking fix without ceasing to be LTS. Node and + the pre-2.6 Linux kernel both used this shape and both paid for it. **Worth choosing + deliberately**: either accept that majors no longer signal breakage, or move LTS-ness out of + the version number (a tag suffix, a channel name) and leave the major for compatibility. +3. **`3.x` is already in use, by the other string.** `VERSION ?= 3.1.0` is the embedded engine. + If `LITHOS_VERSION` takes an odd major it lands on **3.0.0** — two different `3.x` values in + the same generated `include/version.h`. Not fatal, since they are separate fields, but + confusing at precisely the moment a release wants to be legible. **Flag before, not after.** + +### XXIX.4 — CI build numbers: use SemVer build metadata, not a fourth field + +Specific because it interacts with something already shipped. `sbom.spdx` / `sbom.spdx.json` are +generated by **syft** and consumed as SPDX (§XXVI.2), and SPDX/SemVer tooling parses +`X.Y.Z+build.N` correctly while `X.Y.Z.N` is not valid SemVer — it sorts wrongly or is rejected +outright. + +**Recommendation: `2.1.0+ci.1234`.** Build metadata is ignored in precedence comparison, which +is exactly right for a build number: two builds of the same source rank equal, and the SBOM +stays machine-readable for the licensee and patent audiences it exists for. + +### XXIX.5 — What this section rules and what it leaves open + +- ✅ **Policy closed** as §XXIX.2–XXIX.4, subject to Captain Bob ratifying the three conflicts + in §XXIX.3. +- ✅ **`2.1.0` stands** (§XXVIII) — even major, working line. +- 🔶 **LTS deferred, not refused.** Criteria written (§XXIX.2); the first tag meeting them takes + the odd major. +- ⬜ **Captain Bob to rule on §XXIX.3's three conflicts**, and on the engine `VERSION` string + (§XXVIII.4). + +**The disagreement is narrow and worth stating once more so it is not mistaken for reluctance: +the work is real and the tag is deserved. What is not yet earned is the word *long-term +stable*, on code that will be new the day it ships.**