Plan vanity migration and integration releases
This commit is contained in:
@@ -1,7 +1,9 @@
|
||||
# Integration dependency alignment and vanity-path migration
|
||||
|
||||
Status: proposed release-preparation roadmap. This pass adds documentation only;
|
||||
dependency changes and publication remain future work.
|
||||
dependency changes and publication remain future work. The
|
||||
[implementation plan](implementation.md) owns execution stages, concrete tasks,
|
||||
and validation tracking; this roadmap owns the target and selected scope.
|
||||
|
||||
## Purpose and authority
|
||||
|
||||
@@ -111,7 +113,9 @@ new path. Core self-imports, including its `internal` packages, use
|
||||
`go.maximumdirect.net/commandkit/...`; integration self-imports use
|
||||
`go.maximumdirect.net/ckconfig/...` or `go.maximumdirect.net/ckprompt/...`.
|
||||
Cross-module imports and requirements use the complete new paths in the table,
|
||||
including ckprompt's ckconfig dependency.
|
||||
including ckprompt's ckconfig dependency. Core component-version discovery uses
|
||||
`go.maximumdirect.net/commandkit` as its build-info identity, retaining the
|
||||
existing `version --scope commandkit` behavior with the new module path.
|
||||
|
||||
Update production files, tests, maintained examples, and any import-path-based
|
||||
test expectations together. A declared vanity module that still imports the
|
||||
@@ -150,80 +154,26 @@ outcomes. Development workspaces remain useful and ignored. Diagnostic local
|
||||
replacements and the earlier temporary Go shim remain development evidence;
|
||||
release validation uses normal downloaded dependencies without that redirection.
|
||||
|
||||
## Work needed
|
||||
## Release-preparation deliverables
|
||||
|
||||
### Prepare the module-path migration
|
||||
The core v0.3.0 draft describes the complete candidate, including completion,
|
||||
reporting, aliases, tool maintenance, and the vanity-path migration. New
|
||||
integration notes at `integrations/ckconfig/docs/releases/v0.2.0.md` and
|
||||
`integrations/ckprompt/docs/releases/v0.2.0.md` explain the matched dependency set
|
||||
and consumer migration. Their source and licensing links follow the current
|
||||
release procedure; published notes and tags remain immutable.
|
||||
|
||||
Migrate the three module declarations and their owned source/test/example
|
||||
imports using the mapping above. Update CommandKit dependency keys to the
|
||||
vanity paths as each published predecessor becomes available. Preserve package
|
||||
names and aliases unless an actual import-resolution change requires an edit.
|
||||
Current installation examples, README module selections, consumer/developer
|
||||
guidance, affected GoDoc, and maintained examples use the implemented new
|
||||
identities. Import-path-aware tests retain their existing boundary assertions.
|
||||
Source-hosting and license URLs remain repository links, distinct from Go
|
||||
import paths. Module-local attribution describes each actual resolved graph.
|
||||
|
||||
Update current installation examples, module-selection guidance, package links,
|
||||
and dependency descriptions in the README, consumer/developer guidance, and
|
||||
affected GoDoc. Adjust import-path-aware tests to the new identities while
|
||||
preserving their existing boundary assertions. Retain repository/source and
|
||||
license URLs as source-hosting links; they are distinct from Go import paths.
|
||||
Keep historical release records and review evidence accurate instead of doing a
|
||||
repository-wide textual replacement of the old names.
|
||||
|
||||
Ignored development workspaces or disposable module files can support validation
|
||||
before predecessor releases are downloadable. Keep that evidence separate from
|
||||
the independent release graph. The migration may be prepared across all three
|
||||
modules locally, while source publication and final dependency preparation
|
||||
still follow core, ckconfig, then ckprompt order.
|
||||
|
||||
### Prepare and release core
|
||||
|
||||
Review the v0.3.0 draft against changes since the published v0.2.0 tag, including
|
||||
completion, invocation reporting, aliases, and release-tool maintenance. Bring
|
||||
its summary, vanity import migration, compatibility guidance, and immutable
|
||||
source/licensing links into line with the final candidate and current release
|
||||
procedure. Keep published notes and tags unchanged.
|
||||
|
||||
Prepare and commit the core candidate declaring `go.maximumdirect.net/commandkit`
|
||||
on `main`, then use the existing source-publication workflow to publish v0.3.0.
|
||||
Preserve the procedure's required candidate-commit publication before tag
|
||||
publication. The root suite covers the root module; still-pending integration
|
||||
alignment is separate work.
|
||||
|
||||
### Align and release ckconfig
|
||||
|
||||
After core v0.3.0 is published under its new path, prepare ckconfig declaring
|
||||
`go.maximumdirect.net/ckconfig` and requiring
|
||||
`go.maximumdirect.net/commandkit v0.3.0`. Remove the superseded old core
|
||||
requirement, prepare dependencies with workspace discovery off, and tidy the
|
||||
module metadata. Retain authentic sums from actual downloads. No future
|
||||
checksum or local replacement substitutes for the published dependency.
|
||||
|
||||
Prepare `integrations/ckconfig/docs/releases/v0.2.0.md`, documenting the new core
|
||||
requirement, vanity import migration, and reporting/completion behavior. Update
|
||||
affected current guidance and module-local attribution from the actual resolved
|
||||
graph, including immutable notice links. Validate and publish the selected
|
||||
ckconfig candidate through the ordinary module release workflow.
|
||||
|
||||
### Align and release ckprompt
|
||||
|
||||
After ckconfig v0.2.0 is published under its new path, prepare ckprompt declaring
|
||||
`go.maximumdirect.net/ckprompt` and requiring
|
||||
`go.maximumdirect.net/commandkit v0.3.0` and
|
||||
`go.maximumdirect.net/ckconfig v0.2.0` together. Remove the superseded old
|
||||
CommandKit dependency keys. Prepare downloaded dependencies and tidy with
|
||||
workspace discovery off. Retain real sums and inspect indirect changes.
|
||||
|
||||
Prepare `integrations/ckprompt/docs/releases/v0.2.0.md`, covering the compatible
|
||||
dependency set, vanity imports, and consumer migration. Align current guidance
|
||||
and module-local attribution with that selection. Validate and publish its
|
||||
candidate through the ordinary module release workflow.
|
||||
|
||||
### Record the aligned result
|
||||
|
||||
Record the selected module paths and versions, candidate revisions, validation
|
||||
outcomes, and source-publication outcomes separately for all three modules.
|
||||
Update current dependency-readiness statements that still describe this mismatch
|
||||
as unresolved; preserve historical baseline failures in completed review and
|
||||
implementation records. Link future implementation tracking here without
|
||||
restarting the completed ReleaseKit adoption or remediation work.
|
||||
The final record identifies module paths, versions, candidate revisions,
|
||||
validation evidence, and independent source-publication outcomes. Current
|
||||
readiness guidance reflects the aligned state; historical failures remain in
|
||||
completed investigation records. The implementation plan owns the ordered
|
||||
migration, dependency preparation, release, and evidence-recording steps.
|
||||
|
||||
## Validation and completion boundaries
|
||||
|
||||
|
||||
Reference in New Issue
Block a user