-
Notifications
You must be signed in to change notification settings - Fork 579
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
update(renovate): add Go constraint #6476
base: main
Are you sure you want to change the base?
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #6476 +/- ##
=======================================
- Coverage 68.3% 68.3% -0.1%
=======================================
Files 200 200
Lines 16682 16682
=======================================
- Hits 11410 11404 -6
- Misses 4929 4933 +4
- Partials 343 345 +2 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice idea. Have you tested if it would also work for dependencies having Go version < 1.22 and 1.22.x in their go.mod
files?
I have tested that after setting this, the packages that cause the version upgrade of this go version no longer have PRs created. Even if created, they will fail during CI. |
Sure but what about other packages. Are we not going to miss any other updates? |
I can test it. At that time, I will be providing test results. |
I want to confirm what I want to test: Test the other dependent packages that come from the current package. If go<1.22 or 1.22.x exists, does it support it? |
Nice idea! |
Examples of such dependencies are:
You can downgrade their versions and check if renovate would bump both of them. |
They might not be exactly the same. This configuration tends to rely on the current version relationship of Here is an example I am currently using: go-kratos-ecosystem/components#444 I'm not sure if this meets the effect you want. @pellared Additionally, I found that many of the otel package versions are inconsistent, some are Is it allowed to exist like this? |
Yes, but when we drop support for Go 1.22, we need to upgrade this constraint to 1.23. That's what we should document. |
Yes, that is very correct. |
Yes. In general, we are supporting the latest versions of the two newest minor versions of Go. Meaning latest the 1.22 and the latest 1.23. Related issue: |
Under investigation: renovatebot/renovate#33222 |
This ensures that updates to versions that are not supported by 1.22 are avoided. Until you change this configuration item.
https://docs.renovatebot.com/language-constraints-and-upgrading/