wardley-maps.sgit.ai / Admin / Release history
Release history
Every push to dev is a release. The version lives in
admin/build/version.txt, is bumped exactly once per
release, and must also appear in the release commit's subject as
site vX.Y.Z: …. CI verifies the two agree, that the bump is the next minor, and
that this table has a row for it — then tags the release commit. If any of that disagrees,
nothing is tagged and nothing is published.
| Version | Date | What changed |
|---|---|---|
| v0.1.2 | 2026-08-23 | refresh the link-verification report — WardleyPedia is 503, not merely stalled |
| v0.1.1 | 2026-08-23 | un-ignore admin/build/ — the inherited Python .gitignore swallowed the release gate |
| v0.1.0 | 2026-08-23 | First release. The CI pipeline (validate → tag → deploy) and the weekly link-verification job; the doctrine assessment moved from pki.sgit.ai with its evidence links rewritten; 34 resource pages and 11 obituaries, 26 carrying dated screenshots; the PST pattern write-up; four maps shipped as source next to render; the four method claims; the chronology; /shipped/, /agents/, the glossary and the concepts endpoint. |
The scheme
v{release}.{major}.{minor}. Every push to dev is a minor bump;
a major bump to .0 is deliberate and means the site's shape changed rather than its
contents. CI enforces that the new tag is one of those two and refuses anything else, which is
what stops a version being reused or skipped.
Cutting a release
bin/bump.py "what changed" # version.txt + a row in this table python3 admin/build/chrome.py # nav, footer, and the version badge everywhere node admin/build/validate.js # the gate CI will run git commit -am "site vX.Y.Z: what changed" && git push origin dev
The generators — gen_resources.py, gen_dinis.py,
gen_concepts.py, gen_documents.py — run before chrome.py
if their source data changed. The full engineering page →