From 4ca0e9fdae03af784eb1ed86654cf98b92172780 Mon Sep 17 00:00:00 2001 From: Eric Rakestraw Date: Sat, 10 Oct 2026 13:22:38 +0000 Subject: [PATCH] Record the forthcoming module release support --- docs/roadmap/modules.md | 72 ++++++++++++++++++++++++++++------------- 1 file changed, 49 insertions(+), 23 deletions(-) diff --git a/docs/roadmap/modules.md b/docs/roadmap/modules.md index 2ef28f1..fac37ac 100644 --- a/docs/roadmap/modules.md +++ b/docs/roadmap/modules.md @@ -1,7 +1,8 @@ # Optional integration modules Status: module boundary accepted in ADR 0010; implementation planning remains -in progress and no module extraction has begun. +in progress and no module extraction has begun. The next minor ReleaseKit +release will support individual module releases; CommandKit adoption is pending. ## Purpose and authority @@ -146,6 +147,45 @@ shapes merely because they already exist. when changes span modules; independent versions do not imply an exhaustive compatibility matrix. +### Selected multi-module release approach + +Adopt the next minor ReleaseKit version with module-release support. This is a +planned tooling upgrade from the current v0.3.0 baseline, not an implemented +CommandKit capability. Use ReleaseKit's public contracts for checking and +publishing one explicitly selected module per invocation; do not build a separate +CommandKit publication engine or temporary compatibility path. + +Use one shared launcher with small per-module profiles. Each profile selects its +repository-relative module directory and product identity; each invocation +supplies that module's independently selected semantic version. ReleaseKit owns +module-tag derivation, selected-module validation, repository publication guards, +and publication outcomes. Root releases use unprefixed tags. Nested releases use +their Go module-subdirectory prefixes, and notes belong at +`/docs/releases/.md`. Source and licensing links use +the complete Git tag, while note titles identify the product and semantic version. + +Run the selected module's standard suite once with workspace mode disabled and +prepared dependencies. Repository cleanliness, branch, candidate commit, and +endpoint guards remain repository-wide. A root-module release does not implicitly +validate independently released nested modules; composition checks are selected +deliberately where needed. Keep successful source-tag publication as completion, +without CI, hosted delivery, proxy-availability, or installation gates. + +CommandKit's preferred shared file inputs are repository-root `COPYRIGHT`, +`LICENSE`, and `docs/oss/attribution.md`, when present, rather than the entire +root `docs/` tree. Use the forthcoming configurable list or its defaults as +documented by ReleaseKit. Shared inputs affect enabled file checks, not Go suite +scope; resolving references does not add surrounding directories to the inputs. + +Keep module selection and profile lookup repository-relative, module-owned +validation settings and product-command execution module-relative, and diagnostic +paths repository-relative. Use the provided repository context for shared scripts. +Confirm exact profile fields, command syntax, context exposure, and shared-file +selection semantics against the released public documentation during adoption. +These are integration tasks, not remaining choices between publication engines. +Nested-module artifact builds, hosted delivery, and batch publication are not +needed for CommandKit's source-only releases. + ## Work sequence ### 1. Align policy and settle implementation boundaries @@ -235,10 +275,14 @@ exhaustive matrix of historical dependency versions. migration guide. Prepare initial module versions and notes under the [release policy](../policy/release.md); unpublished prototype API changes do not require a compatibility release or a version bump solely for relocation. -- Adapt release profiles, module discovery, validation, note locations, version - reporting, and publication commands to the selected release model. Verify - ReleaseKit's supported capabilities before choosing the mechanics; the current - single-module profile is not evidence of multi-module support. +- Upgrade the module-selected ReleaseKit tool to the next minor release providing + module-release support. Adopt its released public API and CLI/profile contracts + through the shared launcher and per-module profiles described above. Update + launcher checks, validation context, version/tag reporting, and recovery guidance + for selected-module publication; do not duplicate ReleaseKit-owned guards. +- Align the release policy and procedure with module-local notes, independent + versions, full-tag identity, and selected-module validation. Confirm the + documented shared-file defaults or configure the selected files explicitly. - For nested modules, use Go's module-subdirectory tag prefixes and make release-note paths and immutable links unambiguous. Review licensing and attribution visibility in each distributed module under the @@ -282,21 +326,3 @@ redundant private flags and checks rather than reproducing them publicly. represent ownership and collision handling if command groups cannot adequately express those responsibilities. It adds a lasting abstraction, so select it only for a demonstrated consumer or core responsibility, not to imitate current state. - -### Multi-module release mechanics - -Independent versioning is selected. Exact release tooling and per-module note -locations still require investigation of ReleaseKit's supported capabilities. -This is release-workflow design work, not a reason to retain the combined module. - -**Recommendation:** reuse shared publication machinery with explicit module -selection, module-specific versions and notes, and the appropriate tag prefixes. -Validate the selected candidate and publish in dependency order as required by -actual module requirements. Keep the successful source-publication completion -model and avoid duplicate validation of an unchanged final candidate. - -**Alternative:** maintain separate per-module release entry points or profiles -using ReleaseKit's supported mechanisms. This may be simpler if ReleaseKit is -intrinsically single-module, but risks duplicated guards and inconsistent -procedures. Verify its capabilities before selecting exact commands; neither -approach requires matching module versions or a new general release framework.