deps: update dependencies for all modules #7624
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #7624 +/- ##
=======================================
Coverage 81.87% 81.87%
=======================================
Files 361 361
Lines 27813 27813
=======================================
+ Hits 22771 22772 +1
Misses 3847 3847
+ Partials 1195 1194 -1 |
| @@ -1,6 +1,6 @@ | |||
| module google.golang.org/grpc/cmd/protoc-gen-go-grpc | |||
|
|
|||
| go 1.21 | |||
| go 1.22.7 | |||
There was a problem hiding this comment.
Is it necessary to specify a patch version here? Or is this just what go get go@1.22 does?
There was a problem hiding this comment.
This is the default behaviour when running go get go@1.22 && go mod tidy. This change seems to be introduced in the Go toolchain since 1.21: https://tip.golang.org/doc/go1.21#tools
There was a problem hiding this comment.
The issue with specifying the patch version that is not 0 is that now all modules that import this module will have to use this or a newer version. There may be reasons people don't or cannot use the more recent patch version. FWIW I think a library shouldn't have an opinion on the patch version used.
An example of this - we use https://github.com/golang-fips/go/ to provide FIPS-compatible builds. Not all Go versions may be available there e.g. right now there is no 1.23.2. Go 1.22.7 was released 2024-09-05 but FIPS version was tagged 2024-09-27. If grpc-go released a CVE fix in the window of those 22 days, we wouldn't have been able to upgrade.
TL;DR this doesn't benefit grpc-go in any way but might hurt your users.
There was a problem hiding this comment.
All the dependencies for grpc-go are bumped to the latest versions soon after a release branch is cut. If any dependency specifies a patch version > 0, grpc-go will also need to specify at least that version.
There are some measures preventing the example scenario mentioned above:
- Once the Go version is bumped, the change will enter the first release branch after roughly 6 weeks.
- grpc-go does patch releases for recent minor versions. So the security patch would be applied to older releases as well. Older grpc-go releases would be using an older version of Go.
There was a problem hiding this comment.
If any dependency specifies a patch version > 0, grpc-go will also need to specify at least that version.
I understand. This is not under your control, of course. Is this actually happening?
There are some measures preventing the example scenario mentioned above:
Yes. But then I also cannot use the latest version some times.
I can only repeat what I've said already - this doesn't benefit grpc-go in any way but might hurt your users.
There was a problem hiding this comment.
Agree completely with @ash2k. Upgrading the toolchain involves a lot of testing. This library (or any other) should not force patch versions. I think it was a mistake the Go authors even introduced that concept.
There was a problem hiding this comment.
Discussed with other maintainers and we decided to remove the go minor versions: #7831
There was a problem hiding this comment.
lol good call. 👍
Our CI last night saw red across all our microservices via dependabot updates. 😅
Are we able to get a patch release?
There was a problem hiding this comment.
We don't plan to do a patch release for this change alone. If there are bugs discovered in 1.68.0, we may cherry-pick the change into the next patch release.
There was a problem hiding this comment.
How often are minor versions created (ie. is there a v1.69.0 in the works)? If there are no plans for a v1.69.0, and let's say there happen to be 0 bugs nor vulnerabilities in 1.68.0, then people who cannot use go1.22.7 would not be able to use v1.68.0.
If there are plans to get a v1.69.0 out sometime in the near future, then not backporting this fix into v1.68 isn't a huge deal. If there are no plans, then I think this, alone, is worth backporting into v1.68.1 so people can use it.
|
Adding this to the conversation over at: golang/go#65847 Tracking issues related to the changes to the go/toolchain directive |
* update golangci-lint to v1.62.x Signed-off-by: cpanato <ctadeu@gmail.com> * update go to min go1.23.4 Signed-off-by: cpanato <ctadeu@gmail.com> --------- Signed-off-by: cpanato <ctadeu@gmail.com>
Some of the dependencies required
go1.22. Following the release instructions, the minimum go version for all modules is bumped togo1.22.7sincego1.23is the latest release.RELEASE NOTES:
go1.22.7.