go mod:Force dependency to use newer major version of a module?

[email protected]

unread,

Apr 14, 2025, 8:37:15 AM (13 days ago) Apr 14

to golang-nuts

Hello,

My project uses github.com/google/go-github/v71 and one of its dependencies uses an earlier major version of the same module, github.com/google/go-github/v61. Consequently, the compiled binary contains both major versions of go-github, which bloats the binary by about 2MB.

Is there a way to use only the most recent major version?

I tried (in go.mod):

replace github.com/google/go-github/v61 v61.0.0 => github.com/google/go-github/v71 v71.0.0

but running go mod tidy then gives the error:

go: github.com/google/go-github/[email protected] used for two different module paths (github.com/google/go-github/v61 and github.com/google/go-github/v71)

For the full code of the attempt, see this draft PR.

Background info:

* github.com/google/go-github seems to bump its major version every couple of weeks, even when it does not break backwards compatibility.

* I can use the same old version (v61) in my project as in the dependency, but I'd like to keep my project's dependencies up to date.

* I could submit a PR to the dependency to update it to use the latest major version of github.com/google/go-github, but because google/go-github bumps major versions so often, this is not a sustainable long term solution.

So, is there an incantation that I can add to my go.mod to force a dependency to use a newer major version of a module?

Thank you for any insight,

Tom

David Finkel

unread,

Apr 14, 2025, 8:53:34 AM (13 days ago) Apr 14

to [email protected], golang-nuts

Based on the Versioning section of that repo's README, I'm not sure it's wise to blindly bump the major version of another package.

We increment the major version with any incompatible change to non-preview functionality, including changes to the exported Go API surface or behavior of the API

It sounds like they bump the major version when Github API versions do incompatible things as well as when they break their interface (which I take it is less common).

I would have expected a replace directive to work, but, I can also see how that would make the toolchain unhappy with multiple import paths pointed at the same module path.

(unfortunately, I don't have an alternative)

Thank you for any insight,
Tom

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/200df86c-c042-42aa-80ed-a6a6f885d02cn%40googlegroups.com.

[email protected]

unread,

Apr 14, 2025, 11:18:55 PM (12 days ago) Apr 14

to golang-nuts

I doubt you’ll like this answer but the one way i know we’ll work is if you fork the repository, bump the version, and then replace the dep with your fork.

Joe

[email protected]

unread,

Apr 20, 2025, 5:22:04 PM (6 days ago) Apr 20

to golang-nuts

Thank you David and Joe for you replies.

To close this issue for now: the conclusion is that there is no current solution.