firecracker-microvm / firectl

firectl is a command-line tool to run Firecracker microVMs
Apache License 2.0
467 stars 73 forks source link

Go compiler support policy #95

Open austinvazquez opened 1 year ago

austinvazquez commented 1 year ago

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

Kern-- commented 1 year ago

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

austinvazquez commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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-- commented 1 year ago

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 commented 1 year ago

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?