chore: bump go to 1.21 #1208
chore: bump go to 1.21 #1208
Conversation
Signed-off-by: odubajDT <[email protected]>
✅ Deploy Preview for polite-licorice-3db33c canceled.
|
Signed-off-by: odubajDT <[email protected]>
Signed-off-by: odubajDT <[email protected]>
odubajDT
force-pushed
the
chore/bump-go
branch
from
a4ef86a to
d5caf8c
Compare
| @@ -1,6 +1,6 @@ | |||
| module github.com/open-feature/flagd/core | |||
|
|
|||
| go 1.20 | |||
| go 1.21 | |||
There was a problem hiding this comment.
My only concern here is that the flagd go provider uses this module as a library, and it's using 1.20: https://github.com/open-feature/go-sdk-contrib/blob/main/providers/flagd/go.mod
There was a problem hiding this comment.
should be also fine if we merge this as well open-feature/go-sdk-contrib#452. 1.21 should be fully backwards compatible with 1.20
There was a problem hiding this comment.
If that's the case, I guess it won't even be necessary to update the contribs right now at all to consume this? (not that it isn't a good idea anyway).
cc @thisthat @Kavindu-Dodan any concerns?
There was a problem hiding this comment.
I think we should not upgrade all providers in the contrib repository. But we can upgrade flagd provider independently and there are providers already using Go 1.21 (hence the pipeline using the latest Go version).
Similarly, we should upgrade Go-SDK gradually as it's a central piece of OF. I know Go has a backward compatibility promise, but once upgraded and if we use a newer API, then it can impact users who are yet to upgrade their Go version. This could happen for enterprise customers where upgrades are slow and time-consuming compared to Go's 6 month release cycle :)
There was a problem hiding this comment.
Good point, I wasn't aware that some of the users are using parts of the flagd code as a library.
This PR might be then a candidate for 1.0 stable version. At least I would vote for aligning all versions to 1.21.
There was a problem hiding this comment.
@odubajDT it's actually our flagd go provider [1] that depends on the core.
Personally, I am fine with moving ahead with Go 1.21 for flagd. And then we can bump the go provider of flagd itself. But I would avoid changing other providers for sometime :) I hope this is clearer now?
[1] - https://github.com/open-feature/go-sdk-contrib/blob/main/providers/flagd/go.mod#L15
There was a problem hiding this comment.
ohh, and please check for API changes if any in the PR. If there's any, it might be good to mark the PR as a breaking change as we loose forward compatibility for users
|
Closing as this is outdated |
Let's align with the latest Go release
Fixes #1207