Golang 1.18 Upgrade Discussion about go-sdk HOT 10 CLOSED

I agree it's about time, especially since fuzzing is supported natively.

from go-sdk.

I think we could almost seperate the discussion of supported version and generics (to an extent)

When I started work on the SDK I’d thought about using generics per the spec recommendation to use it in a language if available. I think it would be reasonable to support it in golang, but decided not to do it initially as I haven’t seen it widely used in the community yet and figured not using it probably lowers the bar for integration.

The last 2 versions of golang are supported, so I think it’s good practice to target the lower of the two (1.17). That said it’s about to end of life end of Aug, though you imagine some people will trail behind for 3 months or more.

The question is then do we want to support generics ? I think for the next 6-12 months this will still be mixture of users who haven’t embraced generics and those who do. Are any of you guys using generics in your own projects ? I get the feeling that there isn’t an immediate need for it and having a non generics API gives some flexibility with older versions for golang. The flip side is if it gives a better user experience maybe we should adopt it now ?

from go-sdk.

I think we should upgrade to 1.18, consumers of the SDK can upgrade their projects as well to 1.18 without any breaking changes to their projects, and they don't have to use generics if they don't want to.

from go-sdk.

Fuzzing is a repository requirement (go-sdk issue).
Fuzzing is natively supported in 1.18, another reason to consider upgrading.

Note that 1.18 has been available for considerably longer since our last review of this topic (5 months vs 10).

from go-sdk.

Flagd is already using 1.19, which released back in August

https://tip.golang.org/doc/go1.19

from go-sdk.

One of the concerns of upgrading here is to not break compatibility with applications using an older version of Go. This doesn't apply to flagd as external applications don't import it directly.

from go-sdk.

Can a Golang 1.18 library be used in 1.17? If not, we should wait until 1.18 is more widely supported.

from go-sdk.

Can a Golang 1.18 library be used in 1.17? If not, we should wait until 1.18 is more widely supported.

It seems that we could upgrade to 1.18 and be backwards compatible provided that we don't use any of the new features e.g. generics (https://go.dev/ref/mod#go-mod-file-go)

For packages within the module, the compiler rejects use of language features introduced after the version specified by the go directive. For example, if a module has the directive go 1.12, its packages may not use numeric literals like 1_000_000, which were introduced in Go 1.13.

cc @toddbaert @james-milligan

from go-sdk.

It's nice that the compiler rejects the new features, but then in makes the upgrade somewhat less valuable. Still probably worth doing.

After reading your link though, I think that we should add a go directive targeting a specific version, so that we can explicitly agree on minimum supported consumer version.

from go-sdk.

Perhaps we postpone this conversation and pick it back up in a few months. I don't think there's an immediate need to upgrade to 1.18.

from go-sdk.