From f656a2d2e97d927d559313d13102becf3e501923 Mon Sep 17 00:00:00 2001 From: Eric Rakestraw Date: Sat, 10 Oct 2026 01:05:55 +0000 Subject: [PATCH] Preserve simple consumers and resolve module identity once --- docs/roadmap/module-releases.md | 40 +++++++++++++++++++++++++++++++-- 1 file changed, 38 insertions(+), 2 deletions(-) diff --git a/docs/roadmap/module-releases.md b/docs/roadmap/module-releases.md index 40be9f5..13eb41c 100644 --- a/docs/roadmap/module-releases.md +++ b/docs/roadmap/module-releases.md @@ -81,8 +81,11 @@ and complete tag are available throughout candidate handling and public evidence **Work:** Add an optional repository-relative module selection to the public request and profile, with root defaults. Resolve it against the captured -repository and committed module declaration. Derive tags using Go's standard -module conventions, including major-version directories: a `/v2` module stored +repository and committed module declaration once at the operation entry point. +Pass the resolved identity through the operation's validation, publication, +build, and delivery collaborators. Standalone operations use the same resolution +logic. Derive tags using Go's standard module conventions, including +major-version directories: a `/v2` module stored at `integrations/ckconfig/v2` uses `integrations/ckconfig/v2.0.0` for `v2.0.0`. The same module stored at `integrations/ckconfig` uses that complete tag too. Support both physical layouts and distinguish the module directory from its @@ -178,6 +181,8 @@ verified tagged checkout. Resolve the physical module directory and profile before tool bootstrap, and keep the selection consistent with the derived tag. Verify the event commit before resolving that mapping and use the tagged source's selected module files on retries. +For ordinary root tags, use the root profile and module bootstrap defaults. +Consumers using that pattern supply no module/profile mapping declaration. Preserve temporary bootstrap metadata and existing credential handling. Cover major-version directory layouts without assuming that trimming the tag always identifies the physical module directory. Include page-only and binary examples. @@ -199,6 +204,9 @@ showing root and integration profiles and a small shared launcher. Show dependen preparation before offline validation and sequential sibling releases when a dependency version must be published first. Keep product checks focused on consumer assertions instead of repeating the standard suite. +Preserve the [simple root-module experience](#simple-single-module-experience), +including a small +profile, launcher, and CI workflow with no additional required declarations. ### 7. Verify and document the complete behavior @@ -226,6 +234,9 @@ nested-module build/version-injection, new-format receipt ownership and cutover, Gitea page/asset, and CI tag/profile/tool-selection coverage. Use local HTTP servers for delivery and isolated synthetic module proxies for bootstrap tests. Verify that retries use the original module selection and full tag after the default branch changes. +Verify a representative simple root-module API call, profile, launcher, and CI +workflow using the new interface's defaults. Confirm that routine use adds no +required configuration fields, mapping declarations, or consumer decisions. Update GoDoc, CLI/configuration references, check/publication/build/delivery guides, adoption examples, CI templates, and recovery guidance together. Supply migration @@ -241,6 +252,31 @@ examples. Synthetic dependency fixtures use isolated module caches. ## Resolved decisions +### Resolve identity once + +Each ReleaseKit operation resolves repository directory, selected module +directory and declaration, semantic version, and complete tag once through +shared resolution logic. Pass that identity through candidate handling, +validation, callbacks, publication, builds, receipts, delivery, and evidence. +Subsystems consume the resolved module and tag. Repository-state, tagged-source, +and artifact verification continue against that identity through their existing +guards. + +### Simple single-module experience + +Ordinary root-module consumers use the new interface's defaults: omitted module +selection means the repository root, the complete tag equals the semantic +version, notes use `docs/releases/.md`, and validation and builds run +from the root module. Shared-file defaults apply with input deduplication. +Root-tag CI uses the ordinary profile and repository-root tool bootstrap. + +Routine use requires no additional configuration fields, module mapping +declarations, or recurring consumer decisions. A representative root-module +profile, launcher, and CI workflow remain equally small after migration. +Consumers supply their existing product facts through the new interface. +One-time API updates and receipt regeneration belong in the next release's +migration guidance under the clean-cutover decision below. + ### Module boundaries Use committed nested `go.mod` locations as module boundaries for ordinary source