eric/ReleaseKit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Write staged ReleaseKit implementation plan

Browse Source
This commit is contained in:
Eric Rakestraw
2026-10-05 16:15:12 +00:00
parent 43c20b0f61
commit 6c2695f870
2 changed files with 1042 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1024
docs/roadmap/implementation.md Normal file
View File

File diff suppressed because it is too large Load Diff

28
docs/roadmap/releasekit.md
View File

@@ -4,6 +4,8 @@ This is a proposal based on a review of PromptKit, ConfigKit, Audita, Notarius,
Narratio, and Scriptorium on 2026-09-29. Product capabilities remain proposed.
The public facade architecture is accepted in
[ADR 0001](../adr/0001-public-facade.md), with implementation pending.
The [implementation plan](implementation.md) owns ordered stages, execution
instructions, acceptance checks, and progress toward this target state.
## Opportunity
@@ -175,17 +177,23 @@ ReleaseKit should report source publication and artifact delivery separately:
| Woodpecker or Gitea delivery fails after tag publication | Keep the source release successful. Retry missing delivery from the immutable tag after checking existing content. |
| Published source or content needs correction | Publish a new version; never replace content under the published version. |
## First implementation slice
## Consumer adoption target
Pilot the common publication path with PromptKit and Scriptorium, which already
require `main` to equal the candidate and publish annotated tags. Develop the
pilot through the root `releasekit` facade, with implementation behind its
internal boundary and tests exercising the supported consumer contract. Their
different validation and remote configuration will test the proposed boundary.
Migrate the other projects after the shared Git contract is exercised against
temporary remotes. Add common delivery only after publication behavior is
settled, using one of the existing binary-publishing projects as the first
delivery pilot.
All six projects should use the same selected publication, runtime version,
build, and delivery conventions where those responsibilities apply. Repository
entry points should contain only tool invocation and product-specific settings
or checks. Shared mechanics and their repeated tests belong in ReleaseKit.
Application runtime code should obtain version information through `buildinfo`.
Source-only libraries need no runtime import or automatic binary deliverable.
Projects declaring binaries should use the common target selection and version
injection; projects declaring hosted delivery should use content-aware retries.
Existing published tags, notes, pages, and assets retain their historical contents.
Consumer policy and procedure changes should describe the deliberately adopted
standard and its compatibility impact. Adoption should demonstrate reduced local
infrastructure and one coherent release model. The implementation plan owns
pilot selection, migration order, and acceptance evidence.
## Reviewed implementations