Typically a Go project will deal with 2 versions of Go:
- the version of Go installed on the host machine
- the minimum version of Go defined in
go.mod
I don't understand well when to upgrade the version in go.mod vs when not to (if that is ever the case). For example, if I have a locally installed Go 1.16.9, does it make sense to set go 1.19 in the go.mod file? Should the go version in go.mod be on par with the locally installed version of Go? Can it be higher or lower?
Something that confuses me is the term minimum version of Go required by the current module, i.e. is this similar to how Android has a minimum-compatibility version? Does a lower version in go.mod mean the module can be installed on a wider range of machines and is this a good thing?
CodePudding user response：
Ideally you want to use the lowest version you are comfortable with.
If a new standard library function is locked behind a new Go version, then you may decide its important to upgrade Go in order to use that function.
However you should respect that when you upgrade the Go version, you force that new version upon consumers of your module. You may not care about that, but if you do, then it makes sense to use the lowest version you can, in order to serve the largest audience.
CodePudding user response：
It depends.
- With IDEs like goland, you can set up a go version which is different from what you have installed on your local machine. IDE will download and install the selected version also. But that version is valid within your IDE session. So your go.mod can have a different version from go version you installed originally
- Otherwise, if you only have 1 version on your machine, say 1.16.9 and you want to use v1.19 in your go.mod, you would need to install v1.19. or downgrade it in go.mod
- Another question can be whether you should upgrade the go version for your project. Again, it depends on your project. I have had projects where dependencies were on higher version, so I had to upgrade my current project's go version. There will be differences with standard go libraries also with version changes. One common challenge I faced across different versions was around dependency resolution. So you may want to look out for those also.