Update go version

[alan-strohm]

We're on 1.21. As of Feb, 2025 only 1.24 and 1.23 are supported.

[rsned]

Do we want it to be the version the code still works with, or a reasonably current version? (e.g. we use any instead of interface{} so 1.18 is as old as the library can work with)

[alan-strohm]

I assume we want to stay on the lowest version possible (so not 1.24) to not force our clients to upgrade unnecessarily. Options (with associated principles):

• 1.23. Principle: We should use the oldest supported version.
• 1.22. Principle: We should continue supporting versions for a period of time after they are officially unsupported to give clients time to move.
• 1.21. Principle: We should only update when there are new features we want to use (but then maybe we go back to 1.18?)

@flwyd do you have an opinion?

[flwyd]

The Go version in the go.mod file specifies the minimum version of Go which can be used to build the module. It also determines which compiler features are enabled when building. Regardless of the version declared, Go uses the active toolchain to build it: if someone compiles with Go 1.24, they'll get all the compiler benefits, standard library performance improvements, etc. even if our module only declares 1.21.

I tend to think the third principle (only update when we want to use new features of a Go version) is a good idea. We don't get any benefit by declaring a higher version than we need, and it doesn't require someone to upgrade their module's Go version to pick up a new version of the geo package, until we start using a new feature. (This approach is advocated by mingo, for example.) We also don't need to be too conservative about this: if there's a good reason to use a new feature, we shouldn't cling to an old Go version.

Go 1.22 improves the semantics of variables declared in for loops, and allows range over an integer.
Go 1.23 introduces range-over-iterator-functions and the Seq type.

[alan-strohm]

That sounds reasonable to me. So let's not update go.mod.

However, our go.yml currently builds / tests pull requests with go-version-file: 'go.mod'. I think, at a minimum, we should be testing the way we expect our clients to use the library so I'll send a pull request to change that to go-version: 'stable'.

I'll also file a help-wanted issue to enable matrix testing on both stable and the version in go.mod since that'd be a bit better but requires more thought than I have time for at the moment.