Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Major version updates for Go modules #2213

Open
EricByers opened this issue Nov 29, 2018 · 11 comments
Open

Major version updates for Go modules #2213

EricByers opened this issue Nov 29, 2018 · 11 comments
Labels
F: language-support Issues specific to a particular language or ecosystem; may be paired with an L: label. F: version-updates ⬆️ Issues specific to version updates L: go:modules Golang modules T: feature-request Requests for new features

Comments

@EricByers
Copy link

EricByers commented Nov 29, 2018

Add support for upgrading Go modules across major versions by rewriting import paths across the Go project.


Original issue description:

A few vendor libraries we use, make use of gopkg (for instance launch darkly says to use go get gopkg.in/launchdarkly/go-client.v4). In these cases, because the URL itself changes based on major packages, we're never alerted to the changes on dependabot (specifically because the last package would have been go get gopkg.in/launchdarkly/go-client.v3)

Was wondering if there could be specific support for gopkg, which would allow dependabot to open PR's for the update.

@EricByers
Copy link
Author

After writing this I realized that we do not have to use gopkg, and can just use GitHub directly avoiding this issue.

@greysteil
Copy link
Contributor

This is one for @hmarr, but we are planning to support major version update for Go in future. The tricky thing is that Dependabot will need to learn to update import statements to do so, which will likely mean cloning your repo (rather than just fetching the dependency files).

@infin8x infin8x transferred this issue from dependabot/feedback Jun 29, 2020
@hmarr hmarr changed the title Gopkg major version updates Go major version updates Jul 2, 2020
@hmarr hmarr added F: language-support Issues specific to a particular language or ecosystem; may be paired with an L: label. L: go:modules Golang modules T: feature-request Requests for new features labels Jul 2, 2020
@thepwagner
Copy link
Contributor

There's an implementation of this in https://github.com/thepwagner/action-update-go/ that may be inspiration. It works for me: thepwagner/action-update#77

@dependabot dependabot deleted a comment from stale bot Feb 5, 2023
@jeffwidman jeffwidman changed the title Go major version updates Major version updates for Go modules Feb 5, 2023
@jmalloc
Copy link

jmalloc commented Mar 22, 2023

Is there anything I can do to help progress this?

@jeffwidman
Copy link
Member

jeffwidman commented Mar 22, 2023

I'd rather see this land upstream in go mod tooling, and then we leverage that. That will be far less brittle/easier to maintain than us trying to maintain it ourselves, regardless of whether it uses a native helper or (even more brittle) doing it in ruby/regex.

Here's some related upstream issues:

@abdulapopoola abdulapopoola added the F: version-updates ⬆️ Issues specific to version updates label Mar 31, 2023
oxzi added a commit to Icinga/icingadb that referenced this issue Mar 22, 2024
When Go modules mature and their major version has exceeded one, the
module path requires a version suffix, such as "/v2"[0]. Unfortunately,
the Dependabot is unable to detect such a Go module major version bump
for suffixed major versions[1], resulting in stalling dependencies.

By introducing another GitHub Actions Workflow utilizing gomajor[2],
those major version updates for Go modules can be identified. As a
scheduled workflow, running each Monday morning, it will either create
or update an open GitHub issue with all currently available major
version updates for referenced Go modules.

[0]: https://go.dev/ref/mod#major-version-suffixes
[1]: dependabot/dependabot-core#2213
[2]: https://github.com/icholy/gomajor
oxzi added a commit to Icinga/icingadb that referenced this issue Mar 22, 2024
When Go modules mature and their major version has exceeded one, the
module path requires a version suffix, such as "/v2"[0]. Unfortunately,
the Dependabot is unable to detect such a Go module major version bump
for suffixed major versions[1], resulting in stalling dependencies.

By introducing another GitHub Actions Workflow utilizing gomajor[2],
those major version updates for Go modules can be identified. As a
scheduled workflow, running each Monday morning, it will either create
or update an open GitHub issue with all currently available major
version updates for referenced Go modules.

[0]: https://go.dev/ref/mod#major-version-suffixes
[1]: dependabot/dependabot-core#2213
[2]: https://github.com/icholy/gomajor
oxzi added a commit to Icinga/icingadb that referenced this issue Mar 22, 2024
When Go modules mature and their major version has exceeded one, the
module path requires a version suffix, such as "/v2"[0]. Unfortunately,
the Dependabot is unable to detect such a Go module major version bump
for suffixed major versions[1], resulting in stalling dependencies.

By introducing another GitHub Actions Workflow utilizing gomajor[2],
those major version updates for Go modules can be identified. As a
scheduled workflow, running each Monday morning, it will either create
or update an open GitHub issue with all currently available major
version updates for referenced Go modules.

[0]: https://go.dev/ref/mod#major-version-suffixes
[1]: dependabot/dependabot-core#2213
[2]: https://github.com/icholy/gomajor
@gaby
Copy link

gaby commented Jul 8, 2024

@jeffwidman A proposal was accepted to allow golang toolchain to notify of updates to major versions. Dependabot could use this to notify users.

golang/go#67420 (comment)

@jeffwidman
Copy link
Member

jeffwidman commented Jul 8, 2024

Oh nice I hadn't seen that!

Given it's a major version update, it'll have breaking changes beyond just the rewritten import paths.

Since :dependabot: opens PRs, we'll need to account for those changes in the PR body... I wonder if we could leverage Copilot for that? 🤔

@gaby
Copy link

gaby commented Jul 8, 2024

@jeffwidman Maybe for something like this it would be better for dependabot to Open an Issue on the repo or Notify the Repo, instead of creating a PR?

I highly doubt an automatic upgrade of major version would work at all, since it's supposed to be a "breaking change".

@billinghamj
Copy link

billinghamj commented Jul 8, 2024

@jeffwidman I'd much rather it just update the import paths and do absolutely nothing with the remaining code, just as it does with all other ecosystems. If there's been a breaking change, that's for our developers to consider - we would not want Dependabot adding its own opinion on top

If you do want to make code suggestions, that could be a cool feature, but should really be entirely separate from this. It's also applicable to breaking changes in any ecosystem, potentially with any version changes - not just Go, and not just major versions (e.g. Go packages often don't strictly follow semver).

@jmalloc
Copy link

jmalloc commented Jul 8, 2024

I highly doubt an automatic upgrade of major version would work at all, since it's supposed to be a "breaking change".

In my experience there are plenty of situations where this works just fine. For a "classic" example, see http://github.com/google/go-github. The major version of this module is bumped on every release, but it has a large API surface area, much of which is unused by any single dependant module.

@gaby
Copy link

gaby commented Jul 9, 2024

I highly doubt an automatic upgrade of major version would work at all, since it's supposed to be a "breaking change".

In my experience there are plenty of situations where this works just fine. For a "classic" example, see http://github.com/google/go-github. The major version of this module is bumped on every release, but it has a large API surface area, much of which is unused by any single dependant module.

That's true, there some edge cases. So yes, updating the path on each file makes sense, it's up to the dev to fix any issues from the major upgrade.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F: language-support Issues specific to a particular language or ecosystem; may be paired with an L: label. F: version-updates ⬆️ Issues specific to version updates L: go:modules Golang modules T: feature-request Requests for new features
Projects
None yet
Development

No branches or pull requests

9 participants