Migrate ConfigKit to its vanity module path
This commit is contained in:
@@ -1,6 +1,7 @@
|
||||
# Vanity Module Path Migration
|
||||
|
||||
Status: target settled; implementation has not begun.
|
||||
Status: repository implementation complete and locally verified. Exact-revision
|
||||
remote consumer verification awaits availability of the migrated commit.
|
||||
Planning baseline: `21c9bc0ad0315c4ac96268b487a52376558a18d7`.
|
||||
|
||||
This roadmap defines the target and work needed to adopt
|
||||
@@ -201,3 +202,44 @@ application adoption, and release publication are separate outcomes. No push,
|
||||
tag, or downstream change is authorized merely by completing this roadmap.
|
||||
|
||||
No significant open decision remains for this migration.
|
||||
|
||||
## Implementation And Verification
|
||||
|
||||
The module declaration and all ConfigKit self-imports now use
|
||||
`go.maximumdirect.net/configkit`, including internal packages, external-package
|
||||
tests, maintained examples, and benchmarks. The import-boundary predicates and
|
||||
root-type reflection expectations use the new prefix. Review of every changed
|
||||
Go hunk confirmed only the intended module-prefix replacements and publication
|
||||
URL expectation; no loading behavior or public symbol names changed.
|
||||
|
||||
`releasekit.json`, its profile test, and the runbook now use the retained Forge
|
||||
SSH publication endpoint, matching the existing effective `origin` push URL.
|
||||
The runbook distinguishes that transport from Forge HTTPS browser links and
|
||||
vanity-path consumer retrieval. README and the consumer guide identify the new
|
||||
import path; migration guidance covers named-type identity and historical tags.
|
||||
|
||||
The Go minimum, dependency/tool versions, and `go.sum` are unchanged. Historical
|
||||
release records, accepted ADRs, adopted policies, and upstream attribution were
|
||||
left intact. Remaining old ConfigKit path references describe the migration's
|
||||
baseline, consumer upgrade instructions, or historical releases.
|
||||
|
||||
Local validation passed on Linux with Go 1.26.10 and cached dependencies:
|
||||
|
||||
```sh
|
||||
GOTOOLCHAIN=local GOPROXY=off GOTELEMETRY=off ./scripts/check.sh
|
||||
GOTOOLCHAIN=local GOPROXY=off GOTELEMETRY=off go mod tidy -diff
|
||||
GOTOOLCHAIN=local GOPROXY=off GOTELEMETRY=off go test -race ./...
|
||||
```
|
||||
|
||||
The everyday check included maintained examples, documentation links, root type
|
||||
ownership, dependency boundaries, and the release profile. Module/package
|
||||
inspection reported the new main-module identity and no old ConfigKit imports
|
||||
in the assembled test dependency graph. The module-selected ReleaseKit built
|
||||
outside the checkout and reported v0.4.2. Module tidiness produced no diff.
|
||||
|
||||
No push or release was performed. A fresh remote consumer has not yet installed
|
||||
the migrated revision, because that revision has not been published to the remote.
|
||||
The earlier infrastructure checks remain preliminary evidence only. Once the
|
||||
commit is available through an authorized push, the one-time exact-revision
|
||||
consumer check described above can verify retrieval and public-API compilation
|
||||
without a local replacement; it remains separate from release completion.
|
||||
|
||||
Reference in New Issue
Block a user