-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Comments
After writing this I realized that we do not have to use gopkg, and can just use GitHub directly avoiding this issue. |
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). |
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 |
Is there anything I can do to help progress this? |
I'd rather see this land upstream in Here's some related upstream issues: |
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
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
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
@jeffwidman A proposal was accepted to allow golang toolchain to notify of updates to major versions. Dependabot could use this to notify users. |
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 |
@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". |
@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). |
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. |
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 beengo 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.
The text was updated successfully, but these errors were encountered: