Versioning

The four-designator grammar

The canonical version key is a single coordinate with four designators:

v.<Release>.<Era>.<Name>-<fix>

• Release— a major-tier deity. The deity’s leading letter isthe release ordinal: A = 1, B = 2, … Z = Zeus. The ordinal is derived from the letter, never from list or file position. The locked Releases bound to shipped history are Aether (A=1, “Foundation”), Boreas (B=2, “Genesis”), Chronos (C=3, “Chronos”).
• Era— an integer counting the major arcs within a Release.
• Name— a minor figure (a non-reserved Greek / mythological name) drawn within an Era. The Name carries day-to-day identity: operators say “Argus is in flight” instead of reciting the coordinate.
• fix— an optional lowercase-letter patch suffix (-a, -b, …). An absent fix sorts strictly before that Name’s -a.

The full coordinate (Release, Era, Name, fix?) is the canonical key — nothing else is identity. A compact three-letter short code is derived from it only for tight badge real estate; the long coordinate always wins on conflict. The operator-facing build stamp currently surfaces vH.1.19 alongside its Release Chronos.

The retroactive-fix model

Touching shipped work under a historical Name does not open a new head node. It mints a retroactive fix under that Name at its historical coordinate: the next-unused fix letter, minted as the maximum existing fix plus one.

• The first retroactive touch of a Name that shipped with no fix mints -a (the no-fix base still sorts strictly before a).
• The next retroactive touch mints -b, and so on: a → b → … → z → aa (lowercase-letter sequence, with carry).
• A genuinely-distinct newsub-effort under the same old Era is not a fix on the existing Name — it mints a new Name drawn from the unused pool, never a fix letter.

This keeps the patch chain attached to the work it patched: a fix to old Foundation work is numbered under that Foundation Name’s coordinate, not as a brand-new head of the current Release.

Codename uniqueness & Release reservation

Every major-tier deity that occupies a Release slot is permanently reserved. A reserved Release-tier name may never appear at the Name layer, and no codename bound to a shipped coordinate is ever reused. A historical Name that collides with a reserved slot is re-drawn from the unused pool deterministically; it is never silently kept and never used twice.

• Prometheusis a reserved Release-tier deity — any historical Name that landed on Prometheus is re-drawn from the pool so the slot stays uniquely the Release’s.
• Demeteris a reserved Release-tier deity — any historical Name that landed on Demeter is re-drawn from the pool so the slot stays uniquely the Release’s.

Consequence: the de-duplicated Iris node keeps its shipped-coordinate Name while a later planned release that reused “Iris” is re-drawn; and a historical Name colliding with a reserved Release slot — the H-arc Demeter node, re-drawn to Daedalus — is re-drawn rather than reused. A re-draw can also be reversed by an explicit, bounded operator decision (the v0.7.10.x node keeps its historical Prometheus name by sanctioned override); the reservation invariant itself is never weakened — uniqueness is an invariant of the model, not a per-page convention.

The five era kinds

An era is the nature/cycle the work belongs to. There are five canonical era kinds. The three roster eras and their identities are single-sourced from the release roster; the Chaos and Gluon kinds are single-sourced from the typed release dossier — the page itself states only what each kind signifies, never a hand-written membership literal.

• Chaos — the ordered primordial-origin kind: everything built before the first codenamed Foundation era, the pre-roster origin slot. Chaos arcs are ordered for history but pre-date the roster eras. The model-sourced Chaos arcs are Pygmalion, Chiron, Echo, Proteus, Jason, Theseus, Midas.
• Aether (Foundation) — the original pre-Genesis foundation era: all pre-Genesis v0.7.x work. Roster mapping: “Foundation” — “Foundation (all pre-Genesis v0.7.x)”.
• Boreas (Genesis) — the Genesis-refinementera — “the new dawn”, refining what Genesis added. Roster mapping: “Genesis” — “Genesis launch arc”.
• Chronos — the benchmark/scoring-refinement era — the H.1.x benchmark/scoring rehaul arc. Roster mapping: “Chronos” — “The H.1.x benchmark/scoring rehaul arc”.
• Gluon — the orderless cross-cutting maintenance kind: work with no nameable feature identity of its own. Gluon members are orderless (no per-era ordinal, excluded from the feature strict-total-order, date-sorted for display only); bucket identity is by KIND, not by time. Its four thematic buckets, single-sourced from the dossier and the canonical KIND token map, are:
  • Aegis — security/hardening
  • Atlas — deps/infra
  • Angelia — deploy/CI/release
  • Lethe — cleanup/refactor-glue

The era axis and the codename axis are independent: the era reflects the iteration’s cycle, the codename is the stable subsystem identity. A coordinate of the form era-of-the-current-cycle + an older codename + a patch-number is valid and expected.

Governance: how new work is placed

Five canonical rules govern how every future change is placed in the coordinate space. They are the canonical prose statement of the same governance the next-coordinate algorithm enforces.

1. The codename-minting rule. All new work flows through exactly one of four branches: a specmints the next codename in the era at patch-number 1; a feature quick increments a patch-number under the subsystem-owning codename (not merely “the active codename”); a hotfix advances a hotfix-letter within the existing patch-number (it does not increment the patch-number); a maintenance / architectural quick lands in the matching Gluon bucket. There is no third path — every change is exactly one of these four.
2. The subsystem-fold discriminator. Mint a new codename only when a change introduces a distinct nameable capability (spec-sized); add a patch-number when a change refines a capability an existing codename already owns (quick-sized); a maintenance / architectural change with no feature identity routes to a Gluon bucket.
3. The Genesis-0 anchor model. Every codename’s entire existing history is grouped at patch-number 0(its “Genesis” entry); the first future quick is patch-number 1.
4. The modular one-target-per-quick rule. Every future quick must declare exactly one explicit append target (era → codename → patch-number). A request spanning multiple codename positions must be split into multiple quicks.
5. The audit-cycle-codename rule. The audit-cycle codename (Asclepius) is the designated landing place for audit-cycle work; future audit cycles append under it as patch-numbers 1, 2, 3, … An audit-cycle codename’s Genesis-0 can be legitimately empty at spec-start (its prior content faithfully attributed elsewhere); the codename and its node are reserveduntil a real audit cycle lands as patch-number 1. This is a deliberately-reserved-empty state, stated explicitly as doctrine — not a defect.

These rules are the canonical prose doctrine; the portable ChronVer.md specification states the same doctrine project-agnostically, and the placement skill is its executable enforcement.

Codenames carry day-to-day identity

Each coordinate is paired with a Greek / mythological codename. The codename is what the dev team and operators use day-to-day instead of reciting the coordinate; the coordinate is the stable handle that orders work and survives renames.

Shipped

• v.G.0.1Cassandrav0.7.9.x
• v.G.0.2Prometheusv0.7.10.x
• v.G.0.3Pythagorasv0.7.11.x
• v.G.0.4Hydrav0.7.12 l-chain
• v.G.0.5Medusav0.7.12 non-l series
• v.G.0.6Papyrusdocs + spine rehaul
• v.G.1.1Genesis Patchesv.G.1.x post-launch fixes
• v.G.1.3Antikytheracpu benchmark chainweb-tuning
• v.H.1.0Hipparchusbenchmark-score rehaul
• v.H.1.1Pheidippidesbench transport push-primary
• v.H.1.2Argusbench-version admin oversight
• v.H.1.3Daedalusdisk as a first-class benchmark entity
• v.H.1.4Triptolemusgreenlight-gated bench reuse + bulk orchestration
• v.H.1.5Nemesisforward-only red → no-stoicism economic gate
• v.H.1.6Perseusmodel-minted version stamp — the versioning rehaul dogfooded as a shipped node
• v.H.1.7Cadmusthe ChronVer versioning foundation, dogfooded — this spec minted as a shipped node through its own placement procedure
• v.H.1.8Cadmuschangelog/era/naming refinement round — Cadmus.1, the second Cadmus stone laid through the same grammar
• v.H.1.9CharonTriton Panel + fleet/disk benching refinement — Charon.1, the second Charon stone laid through the same grammar
• v.H.1.10CharonStoicism-score display rework on /hub/nodes/ — Charon.2, the third Charon stone laid through the same grammar
• v.H.1.11CharonStoicism / earnings-page rehaul — Charon.3, the fourth Charon stone laid through the same grammar
• v.H.1.12CharonTriton-Panel bulk-benching refinement — Charon.4, the fifth Charon stone laid through the same grammar
• v.H.1.13Charonvirtual-prime commitment-redness + Argus Status-icon column — Charon.5, the sixth Charon stone laid through the same grammar
• v.H.1.14Charonper-server virtual-prime redness consistency + always-one-eligible-disk + forced-rebench button — Charon.6, the seventh Charon stone laid through the same grammar
• v.H.1.15Charonsingle-source virtual-prime display — score + colour computed once server-side, rendered verbatim everywhere — Charon.7, the eighth Charon stone laid through the same grammar
• v.H.1.16Charonsingle-source real-node display — a real node’s score + colour computed once server-side, rendered verbatim everywhere; the three duplicate live-score wrappers collapse to one — Charon.8, the ninth Charon stone laid through the same grammar
• v.H.1.17Charonsingle-source EarnScore — "EarnScore" now means ONE thing everywhere (the take-home capacity score), computed once and rendered verbatim on /hub/nodes and /hub/earnings; the earnings page’s live accrual rate is a separate, clearly-labelled figure — Charon.9, the tenth Charon stone laid through the same grammar
• v.H.1.18Charonsingle-source score program complete — virtual slaves, segregated chainweb children and disk entities each gain one canonical server-computed score+colour, and ServerScoreCard retires its competing colour system; every score entity is now computed once and rendered verbatim everywhere — Charon.10, the eleventh Charon stone laid through the same grammar
• v.H.1.19Caduceushub sovereign Ouronet integration — Caduceus.0, the Genesis stamp of the staff-of-Hermes codename: the herald carrying signed transactions across the boundary between the off-chain hub and the on-chain StoaChain through the same grammar

Launch milestone (in flight)

v.G.1.0 — Genesis. The launch milestone of the Ancient Holdings hub as StoaChain infrastructure support.

Forward roadmap

• v.G.2.0Athenaplanned
• v.G.3.0Icarusplanned
• v.G.4.0Hermesplanned
• v.G.5.0Zeusplanned
• v.G.6.0Mnemosynefuture
• v.G.7.0Atlasfuture
• v.G.8.0Hephaestusfuture
• v.G.9.0Phalanxfuture
• v.G.10.0Nikefuture
• v.G.11.0Aegisfuture
• v.G.12.0Agorafuture
• v.G.13.0Apotheosisfuture

The forward codenames are committed but most have no shipped code yet. Their slot in the coordinate space is reserved; the per-Release plan is what gets edited as each Era moves into design and flight. See the Roadmap pillar for the per-phase mission statements.

The canonical model is authoritative

One file is the single source of truth for everything on this page:

• lib/releases.ts owns the coordinate record, the A–Z deity Release roster, the major-tier classification set, the minor-Name draw pool, the per-Release forest, the strict-total-order comparator, and the retroactive-fix mint rule. Every grammar, retroactive-fix and uniqueness fact above is derived from it — no per-page literals.
• The codename roster and the live build stamp on the chrome are themselves pure derivations of that same model, so the three surfaces (releases, roadmap, this chapter) always agree.

Practical consequence: to add a Release or Era, edit the model. The release pages, the roadmap, and this chapter all update from that edit with no per-page rewrite required.

Legacy-track historical note

The pre-Genesis builds shipped on a legacy semver track. The model maps that entire pre-coordinate history onto Release A — the Foundation Release, whose roster mapping is “Foundation (all pre-Genesis v0.7.x)”. Concretely, every legacy v0.7.x build re-coordinatizes onto the Foundation Release’s nodes, so old operator notes and changelog references stay resolvable while every new release is stamped against the four-designator coordinate only.

The legacy strings are preserved on each Foundation node as its legacyMap — reader infrastructure for the changelog extractors, not an active versioning rule going forward.