Retrospective: R012 (the tag day of 0.1.0)#

Status: ready for the tag on the branch release-0.1.0-final (after R011, accepted at d6483b6). The tag v0.1.0 is pushed on 2026-10-02 (UTC), one day after the final-release pull request (R011, Retrospective: R011 (the final-release pull request for 0.1.0)) wrote the release date 2026-10-01, so R012 makes the tag-day fixes of docs/developer/release.md (A tag day later than the final-release pull request, step 10) and records the decisions the author took on 2026-10-01. Nothing is published by it: the merge, the tag, the GitHub Release and the upload are the orchestrator’s (on the author’s behalf), and the PyPI deployment waits for the author’s approval. R012 is one step done by one implementer.

What changed#

Item

Where

The release date 2026-10-02: ## [0.1.0] - 2026-10-02 and date-released: "2026-10-02"; a “Tag day (R012)” entry in the 0.1.0 section

CHANGELOG.md, CITATION.cff

O3 closed: the NOTICE wording confirmed as drafted (2026-10-01); moved from the open decisions to the approvals log. NOTICE is unchanged

GOVERNANCE.md; docs/developer/plan.md (the M0 status, the open decisions, “Closed later”)

Zenodo not connected for 0.1.0 (no DOI) (2026-10-01): a row of the approvals log; the release guide (who does what, step 12), the repository settings (row 14 and section 14), the citing page, the roadmap and the developer plan no longer say 0.1.0 may or will get a DOI

GOVERNANCE.md, docs/developer/release.md, docs/developer/repository_settings.md, docs/citing.md, docs/roadmap.md, docs/developer/plan.md

The licence expression: a row of the approvals log (2026-10-02): the author was told that it is in the 0.1.0rc1 distributions on TestPyPI and raised no objection by the tag day; the author’s approval of the pypi deployment is the final confirmation

GOVERNANCE.md; docs/developer/release.md step 10

A section of the release guide for a tag day later than the final-release pull request (the procedure of R011’s note, made a part of the guide)

docs/developer/release.md, “A tag day later than the final-release pull request”

The R011 retrospective: an “Afterwards (R012)” paragraph and the outcome of each note (the date, O3, the licence expression, Zenodo)

docs/developer/retrospectives/R011.md

The checks of the packaging and repo scopes run again and recorded; the certificate written again

benchmarks/results/0.1.0/

python ci/wheel_check.py --release-metadata --release-date 2026-10-02 passes, and so does --release-date today (run on 2026-10-02 UTC).

The certificate#

CHANGELOG.md and CITATION.cff are in the packaging scope and in the repo scope (the whole tree but benchmarks/results/); GOVERNANCE.md and the documents are in the repo scope. So, after the last change outside benchmarks/results/ (the commit of this retrospective), these checks were run again from fresh clones of that commit and recorded with parity/certify.py check --version 0.1.0, replacing the records of the same names:

Check

Scope

What was run

distributions

packaging

release.yml’s select for v0.1.0 (and the refused v0.1.0rc1, v0.1.0-rc.1), ci/wheel_check.py --release-metadata --release-date today and --release-date 2026-10-02, ci/wheels.sh, twine check --strict, ci/wheel_check.py --platform manylinux_2_28_x86_64 --require-libgomp, the wheel alone in fresh Python 3.12 / 3.13 venvs with the wheel’s test subset and the README quickstart

check-parity

repo

ci/check.sh --parity (with ci/docs.sh and ci/python.sh also on their own)

gpu_local

repo

ci/gpu_local.sh (dev-cuda, GPU 1)

The other records stand: the gates, the golden replays, the sssp golden mutations and the equivalence record (library scope) and the C++ test suites asan, tsan and mutation-ctests (tests scope, measured at 454e61f): no path of these scopes changed (README.md and the test paths are unchanged), which parity/certify.py write --version 0.1.0 verifies for every part. It wrote benchmarks/results/0.1.0/parity.json naming 0.1.0 and the final commit; the results, commits, dates and logs of the checks are in the certificate (benchmarks/results/0.1.0/README.md, “Checks”).

Deviations and decisions (each with the same intent)#

  1. Older retrospectives are not edited. INT1, M4, M2b, M5 and R010 mention O3 as open or the Zenodo choice for 0.1.0 as still to be made; they are the records of their milestones and stay as written (as R010 did with the M5 readiness list). R011 is annotated, since the milestone asked for its notes to be updated: its statements are kept and marked as R011’s state, with the outcome next to each.

  2. The licence row is a new row, dated the tag day, rather than an edit of the row of 2026-09-30 (an approvals log is appended to, not rewritten). Its “Approved by” cell says what happened: no objection by the tag day; the final confirmation is the pypi approval.

  3. The release guide gained a section for a late tag day, written from R011’s note to the orchestrator, so the next release follows the guide instead of a retrospective.

  4. The checks ran in the order of R011’s note: the repo checks after the last change outside benchmarks/results/ (this retrospective), so this retrospective names their results by reference to the certificate.

Notes for the orchestrator#

  • Merge with a merge commit (ADR 0019), then tag v0.1.0 on main on 2026-10-02 (UTC): run python ci/wheel_check.py --release-metadata --release-date today first. If the tag slips past 2026-10-02, the date must move again (A tag day later than the final-release pull request).

  • Nothing is open for the author before the tag: O3 is closed, the licence expression stood without objection, and Zenodo is not connected for 0.1.0 (no DOI; no step 12 for 0.1.0). The author’s approval of the pypi deployment remains, and it is the final confirmation of the licence expression.

  • After the release (step 14): bump VERSION to 0.1.1.dev0 or 0.2.0.dev0 in a pull request, announce, and carry over the R010 note on parity/cycle_count_perf.py.