Build: set 1.17 as minimum supported Go version

[alexandear]

The PR sets Go version in the go.mod to 1.17 and run go mod tidy.
Also, adds Go 1.23 to CI.

[JoeKar]

The PR sets Go version in the go.mod to 1.19 and run go mod tidy. Looks like this is the minimum-supported Go version for the project.

Currently I'm not aware of if the build is still possible with something lower than 1.19, but at least the whole build and test infrastructure uses this fixed version.
I can live with that.

Can you please rebase the history of your PR to split the changes of go.mod, go mod tidy and build tags into separate commits?

[Andriamanitra]

Currently I'm not aware of if the build is still possible with something lower than 1.19, but at least the whole build and test infrastructure uses this fixed version. I can live with that.

I was able to build micro with a go version as old as go@1.17 (linux/amd64). If I go down to go@1.16 the build starts failing due to internal/clipboard/clipboard.go:6:2: //go:build comment without // +build comment.

Of course "happens to work on this version" does not necessarily mean the same thing as minimum supported version.

[JoeKar]

If I go down to go@1.16 the build starts failing due to internal/clipboard/clipboard.go:6:2: //go:build comment without // +build comment.

So it didn't match this minimum go version requirement either.
Since the test action was introduced more than 1 year ago (via d1af21f) with go@1.19 I recommend that we stick to a min. version of 1.19 as long as possible, to have it somehow comprehensible.

PS:
1.19 is in golang stable (bookworm) and backported to oldstable (bullseye).

@dmaluka
What is your opinion?

[dmaluka]

Currently I'm not aware of if the build is still possible with something lower than 1.19

It so happens that I've been building micro with 1.17 on my primary machine all this time, so I can confirm that 1.17 actually works for us.

So, do we have any actual reason to require 1.19 as the minimum version? If not, I'd suggest we stick to 1.17 for now. Why unnecessarily complicate lives of users who want to build micro with an older version of Go?

but at least the whole build and test infrastructure uses this fixed version.

In fact even that turns out to be not exactly non-controversial. There has just been a report of an unfortunate regression we introduced in 2.0.14: #3463

[alexandear]

Currently, only Go 1.22 and 1.23 is supported according to the release policy. So, even Go 1.19 is deprecated.

---

Can you please rebase the history of your PR to split the changes of go.mod, go mod tidy and build tags into separate commits?

Done.

[dmaluka]

Currently, only Go 1.22 and 1.23 is supported according to the release policy. So, even Go 1.19 is deprecated.

That is Go release policy, not our release policy.

Thanks for the note though, it seems a good idea to bump up Go from 1.19 to 1.22 or newer in our build infra.

Which doesn't mean that we should prevent users from building micro on their own with an older Go version if they want to.

[JoeKar]

So, do we have any actual reason to require 1.19 as the minimum version? If not, I'd suggest we stick to 1.17 for now.

Ok, I've no problem with that either. So we bump go 1.16 to go 1.17 in go.mod and...

Thanks for the note though, it seems a good idea to bump up Go from 1.19 to 1.22 or newer in our build infra.

...do so.

[dmaluka]

So we bump go 1.16 to go 1.17 in go.mod

And also update this sentence in README.md: "Make sure that you have Go version 1.16 or greater and Go modules are enabled."