Clarify the Gitea hostname migration in the roadmap

This commit is contained in:
2026-11-01 14:28:10 +00:00
parent f97edeb830
commit 56a86d6d49

View File

@@ -27,6 +27,10 @@ The baseline is v0.4.2, commit
[maintainer runbook](../release.md) still identify the older Gitea host and
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
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`.
- Version injection, API checks, consumer fixtures, and maintained workflows
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
workflow updates. The Go consumer minimum remains 1.26.0.
- 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,
and licensing footer required by the release procedure. Select an unused
version during release preparation if v0.5.0 has become occupied.
- Review live repository URLs and delivery settings separately from module
identifiers. The vanity path names Go packages; the forge owns Git transport,
source navigation, and hosted release pages. Resolve the delivery question
below and update its owning configuration and runbook accordingly.
- Update ReleaseKit's delivery profile, maintainer runbook, related fixture
expectations, and current hosting links for Gitea at
`forge.maximumdirect.net/base-layer/releasekit`. The vanity path names Go
packages; repository URLs address Git transport, source navigation, and hosted
release pages. Preserve historical release records and their source URLs.
### 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
the release policy. Track source publication and hosted-page delivery
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.