base-layer/releasekit
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 5 Wiki Activity

Clarify the Gitea hostname migration in the roadmap

Browse Source
This commit is contained in:
Eric Rakestraw
2026-11-01 14:28:10 +00:00
parent f97edeb830
commit 56a86d6d49
1 changed files with 12 additions and 26 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
docs/roadmap/migration.md
View File

@@ -27,6 +27,10 @@ The baseline is v0.4.2, commit
[maintainer runbook](../release.md) still identify the older Gitea host and [maintainer runbook](../release.md) still identify the older Gitea host and
repository location. repository location.
The Gitea service now uses `forge.maximumdirect.net`, replacing
`gitea.maximumdirect.net`. The hostname uses the generic term "forge" for a
software hosting service; the software remains Gitea.
### Vanity-path readiness evidence ### Vanity-path readiness evidence
The initial assessment used Go 1.26.10, disposable consumer modules, and isolated The initial assessment used Go 1.26.10, disposable consumer modules, and isolated
@@ -56,6 +60,9 @@ the [Go Modules Reference](https://go.dev/ref/mod#module-path).
- The CLI package is `go.maximumdirect.net/releasekit/cmd/releasekit`. - The CLI package is `go.maximumdirect.net/releasekit/cmd/releasekit`.
- Version injection, API checks, consumer fixtures, and maintained workflows - Version injection, API checks, consumer fixtures, and maintained workflows
operate with the new module identity. operate with the new module identity.
- ReleaseKit's hosted release pages use Gitea at `forge.maximumdirect.net`,
owner `base-layer`, repository `releasekit`, matching the existing Git remote
and vanity mapping.
- Current adoption guidance explains coordinated import, dependency, tool, and - Current adoption guidance explains coordinated import, dependency, tool, and
workflow updates. The Go consumer minimum remains 1.26.0. workflow updates. The Go consumer minimum remains 1.26.0.
- v0.5.0 introduces the new identity with release notes explaining the migration. - v0.5.0 introduces the new identity with release notes explaining the migration.
@@ -113,10 +120,11 @@ migration steps.
- Prepare `docs/releases/v0.5.0.md` with the compatibility impact, upgrade steps, - Prepare `docs/releases/v0.5.0.md` with the compatibility impact, upgrade steps,
and licensing footer required by the release procedure. Select an unused and licensing footer required by the release procedure. Select an unused
version during release preparation if v0.5.0 has become occupied. version during release preparation if v0.5.0 has become occupied.
- Review live repository URLs and delivery settings separately from module - Update ReleaseKit's delivery profile, maintainer runbook, related fixture
identifiers. The vanity path names Go packages; the forge owns Git transport, expectations, and current hosting links for Gitea at
source navigation, and hosted release pages. Resolve the delivery question `forge.maximumdirect.net/base-layer/releasekit`. The vanity path names Go
below and update its owning configuration and runbook accordingly. packages; repository URLs address Git transport, source navigation, and hosted
release pages. Preserve historical release records and their source URLs.
### 4. Verify the migration ### 4. Verify the migration
@@ -150,25 +158,3 @@ Publication follows the existing [release procedure](../release.md). Reuse
successful validation where it applies to the exact candidate, as allowed by successful validation where it applies to the exact candidate, as allowed by
the release policy. Track source publication and hosted-page delivery the release policy. Track source publication and hosted-page delivery
separately under that procedure. separately under that procedure.
## Open Decisions
### Destination for ReleaseKit's hosted release pages
**Recommendation:** Align ReleaseKit's own delivery profile and maintainer
guidance with the Forgejo repository at `forge.maximumdirect.net`, owner
`base-layer`, repository `releasekit`. Confirm the destination's supported
Gitea-compatible API and credential setup when configuring delivery. This
matches the existing Git remote and vanity mapping and gives maintainers one
repository location for source and hosted release pages. It requires updating
delivery configuration, related fixture expectations, and current hosting links
where appropriate.
**Alternative:** Retain the existing Gitea delivery endpoint if it remains an
intentional alias or supported delivery destination. This can preserve working
automation and reduce hosting changes during the module migration. Its value
depends on that endpoint continuing to address the intended repository; the
runbook would need to explain the relationship to the Forgejo origin.
This hosting choice is independent of the module declaration. Source migration
and offline verification can proceed while the delivery destination is resolved.