Go compiler support policy

[austinvazquez]

This thread is to host some discussion on compiler support for the firectl tool.

[Kern--]

Since firectl is a binary and not a library, I think we can be pretty aggressive about which go versions we support.

[austinvazquez]

Discussion with @Kern-- offline, the pipeline is experiencing some build repro issues even with my attempt at a pinning versions, #93, because of the go get -u I used with the older compiler versions. But as mentioned above even if resolved there isn't too much value gained in keeping support for the older compiler versions if users can just grab the binary from GitHub.

[ginglis13]

Agreed, my first instinct as a user when it comes to this package is to use the binary. One of my pain points as a user of this package in the past was out of date binaries (rather, incompatible with latest versions of Firecracker) and having to clone/build myself.

My opinion is to be aggressive with Go versions we support, and after that decision/upgrade in supported versions, release v0.2.0 as a fast follow to address #82

[austinvazquez]

Upgrading Go compiler is currently limited by buildkite instances pinned to Go1.15 for minimum firecracker-go-sdk validation. For firectl, would a docker build solution be attractive so we can push the boundary on compiler versions?

CC: @ginglis13, @Kern--

[Kern--]

Personally, I think it would be better to get our CI infrastructure to run with docker rather than use make targets that use docker, but I'm open to discussion on that.

For now, I think it's ok to update the buildkite hosts to just use Go 1.17.

[austinvazquez]

Personally, I think it would be better to get our CI infrastructure to run with docker rather than use make targets that use docker, but I'm open to discussion on that.

Would make just use the local Go installation?