Separate example setup from synthetic test releases

This commit is contained in:
2026-10-10 14:27:47 +00:00
parent c09c7a2ac7
commit 8552f92ddb
10 changed files with 165 additions and 10 deletions

View File

@@ -64,6 +64,13 @@ Update callers, profiles, receipts, and CI declarations together for this
clean interface cutover; compatibility shims and legacy receipt readers are
not provided.
Select this feature's ReleaseKit release in each consumer module before adopting
the new profiles and workflows. Upgrade its tool declaration and workflow
together: pre-feature tools through v0.3.0 require their historical profiles and
flags. Historical tag retries use the workflow matching the tool recorded at
that tag. Preserve the immutable
tag and module files when retrying.
- Set `ModuleDir` in Go requests or `module_dir` in profiles for a nested
module. The selected directory must contain its own `go.mod`; module paths
and release tags are read from that declaration, not inferred from a folder
@@ -102,3 +109,11 @@ For current behavior, see the [API and consumer guides](../consumers/),
[CLI contract](../cli.md), [configuration reference](../config.md),
[Gitea integration](../integrations/gitea.md), and
[ReleaseKit release procedure](../release.md).
## Release preparation
Once this release's version is selected, record it in the maintained multi-module
example's tool and require directives, and move these notes to its release-note
path. Example setup currently selects a compatible version explicitly; disposable
fixtures can verify current source before publication. Synthetic dependency
versions belong to generated test metadata and local fixture proxies.

View File

@@ -293,7 +293,16 @@ coverage.
## Issue 9: Separate synthetic bootstrap versions from maintained examples (P2)
Status: open. Category: broken adoption example and incomplete cutover guidance.
Status: complete. Category: broken adoption example and incomplete cutover guidance.
**Completion:** Maintained module skeletons no longer pin synthetic releases.
Example setup explicitly selects compatible released tooling and documents source
verification in disposable checkouts. Workflow fixtures generate their synthetic
declarations. Current-source tool registration and all three example profiles,
including native version injection, pass offline; mapped launchers/workflows and
tagged-tool retries retain isolated fixtures. Adoption and migration guidance
cover coordinated tool/workflow upgrades and historical retries. The pending
release notes record concrete example pins as normal version-selection work.
**Evidence:** All three maintained
[multi-module declarations](../../examples/multi-module/) require ReleaseKit