fix(release): derive release tag from the normalized Go-module subdir (v0/v1)#7
Merged
Merged
Conversation
Go disallows a /v1 module path suffix (only /v2+ are allowed), so the v0/v1 line's published module has no version suffix and its release tag must drop the line segment (proto/x/v1 -> tag proto/x/v1.0.0); v2+ keep it (proto/x/v2 -> tag proto/x/v2/v2.0.0). DeriveTag and TagManager.ListVersionsForAPI now route through a new DeriveTagPrefix (= DeriveGoModDir) so a release tag resolves as a version of the published Go module, and forward/reverse tag handling stay consistent. Fixes finding #3 of #5.
The v1 line's release tag no longer carries the /v1 segment (proto/payments/ledger/v1.0.0-beta.1); update the inspect Tag assertions and the publish_ledger derived-tag check + setup tag. v2 tags are unchanged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Release tags were derived as
<api-id>/v<version>, where the api-id includes the version line(e.g.
proto/payments/ledger/v1). For the v0/v1 line that produced a tag likeproto/payments/ledger/v1/v1.0.0-alpha.1, which does not resolve as a version of the publishedGo module.
Go's semantic-import-versioning rule: a module path must not carry a
/v1suffix (only/v2+):So the v1 line's module is
…/proto/payments/ledger(no suffix — which apx already derivescorrectly for
go.mod), and its tag must therefore beproto/payments/ledger/v1.0.0-alpha.1. apxhad applied the "strip the version suffix" rule to the module path but not the tag.
This is finding #3 of #5, and the reason a freshly cut tag could not be
go get-ed.Fix
New
config.DeriveTagPrefix(apiID)returns the normalized Go-module subdirectory (=DeriveGoModDir):v0/v1 drop the line segment, v2+ keep
/vN. Both the forward path (DeriveTag) and the reversepath (
TagManager.ListVersionsForAPI) route through it, so tags resolve as module versions andforward/reverse stay consistent:
…/proto/payments/ledgerproto/payments/ledger/v1.0.0-alpha.1…/proto/payments/ledger/v2proto/payments/ledger/v2/v2.0.0(unchanged)ListVersionsForAPIalso skips tags that belong to a deeper module sharing the v0/v1 prefix(e.g. a
…/v2/tag), so each line lists only its own versions. Callers already filter by linemajor via
LatestVersion, so the shared v0/v1 prefix is safe.Tests updated accordingly (
TestDeriveTagincl. v0/v2 cases;tags_testfixtures now use the realscheme and exercise the deeper-module skip; manifest/record/report assertions).
go build,go vet, andgo test ./internal/... ./cmd/... .pass.Scope
Findings #2 (finalize unwired in canonical CI) and #4 (auth login token persistence) of #5 remain
open.