feat: update go version for release

[hrvolapeter]

Go since version 1.16 supports darwin/amd64 and go-releaser supports this target from v0.156.0 so as far as I can tell this is the only change needed to support darwin/amd64 target

[verdverm]

The yaml files are generated from CUE

https://github.com/cue-lang/cue/blob/master/internal/ci/workflows.cue

Not sure if it is worth updating the workflow schema (via cue import), there were some fixes & additions upstream

[verdverm]

@myitcv can releases be built with the latest Go version while still maintaining the two supported Go version parity?

Go 1.17 added windows/arm64 port

[myitcv]

@hrvolapeter welcome to the CUE project!

We tend to prefer raising issues in the first instance to help flesh out the detail of any change. Not least because an issue might actually give rise to a number of changes, hence the issue and discussion will outlive one of those changes.

There are a few things we probably want to address here:

• expanding the build matrix to include Go 1.17
• building CUE release artefacts with the latest version of Go
• expanding the release matrix to include new Go ports
• testing all the above (somewhat related to goreleaser test goreleaser/goreleaser#2355))

Is there anything I'm missing from the list above?

@myitcv can releases be built with the latest Go version while still maintaining the two supported Go version parity?

Go 1.17 added windows/arm64 port

@verdverm we used to build with the latest version of Go. Looks like when I updated our build matrix from 1.16.0-rc1 to 1.16 I didn't flip to define 1.16 (at the time) as the latest stable version of Go. We can fix that in whatever changes come from this discussion.

[verdverm]

@myitcv another update in 1.17 I was thinking might be helpful for API users is the dependency pruning. That would require updating the Go directive in go.mod. Thoughts?

Another thought, is there preference for including (or not) the patch version in the workflows? (i.e. 1.16 vs 1.16.5) Any implications on reproducibility, like a new patch version released between final commit testing and tagging for a release?

(adding here until there is a discussion issue created)

[hrvolapeter]

I've created an issue with the summary of points discussed here. #1225

[hrvolapeter]

@myitcv I've added changes for 1. in #1225

a) adding Go 1.17
b) ensuring that the latest version of Go is used for build artefacts
c) adding new ports to the release targets doesn't seem to be necessary since go releaser should start to create darwin-arm64 artifacts automatically if Go version is higher than 1.16