Skip to content

Point module path at this fork - #25

Merged
rethab merged 1 commit into
mainfrom
migrate-module-path-to-fork
Jul 12, 2026
Merged

Point module path at this fork#25
rethab merged 1 commit into
mainfrom
migrate-module-path-to-fork

Conversation

@rethab

@rethab rethab commented Jul 12, 2026

Copy link
Copy Markdown
Owner

go.mod still declared the module as github.com/ankitpokhrel/jira-cli, so this fork's own packages were all imported through the upstream path. Anyone go install-ing or importing from rethab/jira-cli would get a module whose declared path disagrees with where it actually lives, and the two would be treated as separate modules if both ended up in one build graph.

The build configs hardcoded the same path, which is the part that could ship broken silently: the -X ldflags in Makefile and .goreleaser.yml inject version/commit into internal/version, and a -X against a package path that isn't in the binary is a no-op rather than an error. Left as-is after a module rename, releases would build fine and report an empty version. Verified by building through the Makefile and confirming jira version still reports the injected values.

README badges and links to upstream discussions/issues are deliberately untouched — those point at the upstream project's community, not at code, and are a separate call to make.

The module was still declared as github.com/ankitpokhrel/jira-cli, so every
internal import resolved through the upstream path and the release ldflags
targeted upstream's version package.
@rethab
rethab merged commit 8d0fbba into main Jul 12, 2026
1 check passed
@rethab
rethab deleted the migrate-module-path-to-fork branch July 12, 2026 05:57
rethab added a commit that referenced this pull request Aug 5, 2026
`go.mod` still declared the module as
`github.com/ankitpokhrel/jira-cli`, so this fork's own packages were all
imported through the upstream path. Anyone `go install`-ing or importing
from `rethab/jira-cli` would get a module whose declared path disagrees
with where it actually lives, and the two would be treated as separate
modules if both ended up in one build graph.

The build configs hardcoded the same path, which is the part that could
ship broken silently: the `-X` ldflags in `Makefile` and
`.goreleaser.yml` inject version/commit into `internal/version`, and a
`-X` against a package path that isn't in the binary is a no-op rather
than an error. Left as-is after a module rename, releases would build
fine and report an empty version. Verified by building through the
Makefile and confirming `jira version` still reports the injected
values.

README badges and links to upstream discussions/issues are deliberately
untouched — those point at the upstream project's community, not at
code, and are a separate call to make.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant