docs: add a release-algorithm diagram - #778
Conversation
There was a problem hiding this comment.
Docs-only addition (docs/diagrams/release-algorithm.md + index). Cross-checked the diagrams and the ordering claims against the actual implementation (src/monorepo/run/{mod,execute,checkpoint,lock}.rs) — lock-before-mutation, commit-graph write, single tag_foreach pre-collection, execute_release step order (commit → tags → push → forge → post-publish), checkpoint phase ordering/HEAD-pinning/stale handling, and push-before-publish all match the code exactly, including the #770/#549/#514 history referenced in comments.
Nit: "18 modules under src/formats/, each owning one file shape" overcounts slightly — of the 18 files in that directory, mod.rs (dispatch table) and splice.rs (shared helper) aren't format-specific, and lockfiles.rs covers multiple lockfile kinds rather than one shape. Only 15 modules map 1:1 to a FileFormat variant. Not worth blocking on, just a number to tighten if this doc gets revisited.
Closes #777
Documents what happens between reading the commits and the release existing, with the reasoning behind the ordering.
Covers the analysis phase (release lock, commit-graph write on fresh clones, the single
tag_foreachpre-scan that collapses per-package tag lookups fromO(tags)callbacks +O(commits)walk toO(1), and the changelog section built once so hooks, tag body and release notes cannot disagree), thenexecute_releasewith an explicit note on why git lands before the forge and whyfiles_to_commitis snapshotted after pre-commit hooks.Includes the checkpoint state machine as a
stateDiagram-v2— the six phases, the pinning to HEAD, and the deliberate refusal to resume when the repo has moved.The manifest section records the rule that matters most for user trust: format writers splice the version in place and never reserialise, because reformatting someone's
Cargo.tomlis a bug rather than a side effect.