On Mon, Apr 14, 2025 at 9:37 AM twp...@gmail.com <twpa...@gmail.com> wrote:
> 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/v71@v71.0.0 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 > <https://github.com/twpayne/chezmoi/pull/4403>. > > 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? > Based on the Versioning section of that repo's README <https://github.com/google/go-github?tab=readme-ov-file#versioning>, 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 golang-nuts+unsubscr...@googlegroups.com. > To view this discussion visit > https://groups.google.com/d/msgid/golang-nuts/200df86c-c042-42aa-80ed-a6a6f885d02cn%40googlegroups.com > <https://groups.google.com/d/msgid/golang-nuts/200df86c-c042-42aa-80ed-a6a6f885d02cn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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 golang-nuts+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/golang-nuts/CANrC0Bi5yZuOc1F%3DD4kcPe3MMrfUNBW7VkdKHK1GWAnk%2B5u0Aw%40mail.gmail.com.
