lean

Release process

How a version of this repository becomes a citable release. Reader-facing documents state release facts and link here; the mechanics live on this page only.

Order of operations

1. The tree is positioned as released: version, date-released, CHANGELOG entry, and README currency all state the release as fact.
2. The annotated tag and GitHub release are built on that tree.
3. The GitHub release creation — not the tag alone — mints the Zenodo version DOI and drives the deposit under concept DOI 10.5281/zenodo.20369489.
4. The minted version DOI is recorded back into the tree afterward.

The tree leads the release. Zenodo archives the tree as-is, so the tree carries the release date (an operator decision) but never a predicted version DOI (a value Zenodo emits). A GitHub release does not by itself prove the corresponding Zenodo version exists; each is verified independently.

The two DOI kinds never trade places: the root (concept) DOI 10.5281/zenodo.20369489 identifies the series, resolves to the latest published version, and never changes across releases — it is what CITATION.cff carries permanently. Version DOIs are per-release, minted at deposit, and recorded in the release record, never in place of the root.

Verification notes

• Every release-gating check is a bare command whose exit code decides pass/fail; the full list is in AGENTS.md.
• GitHub Pages renders main’s README.md. After a push, the rendered body and response headers are verified independently; a stale render is a cache fact, not a release fact.
• git rev-parse HEAD identifies the exact local source being built when reproducing any receipt.

Tags, GitHub releases, and Zenodo deposits are operator-only acts; see the hard limits in AGENTS.md.

This site is open source. Improve this page.