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：

It depends.

1. 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
2. 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
3. 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.

CodePudding user response：

Introduction Modules are how Go manages dependencies.

This document is a detailed reference manual for Go’s module system. For an introduction to creating Go projects, see How to Write Go Code. For information on using modules, migrating projects to modules, and other topics, see the blog series starting with Using Go Modules.

Modules, packages, and versions A module is a collection of packages that are released, versioned, and distributed together. Modules may be downloaded directly from version control repositories or from module proxy servers.

A module is identified by a module path, which is declared in a go.mod file, together with information about the module’s dependencies. The module root directory is the directory that contains the go.mod file. The main module is the module containing the directory where the go command is invoked.

Each package within a module is a collection of source files in the same directory that are compiled together. A package path is the module path joined with the subdirectory containing the package (relative to the module root). For example, the module "golang.org/x/net" contains a package in the directory "html". That package’s path is "golang.org/x/net/html".

Module paths A module path is the canonical name for a module, declared with the module directive in the module’s go.mod file. A module’s path is the prefix for package paths within the module.

A module path should describe both what the module does and where to find it. Typically, a module path consists of a repository root path, a directory within the repository (usually empty), and a major version suffix (only for major version 2 or higher).

The repository root path is the portion of the module path that corresponds to the root directory of the version control repository where the module is developed. Most modules are defined in their repository’s root directory, so this is usually the entire path. For example, golang.org/x/net is the repository root path for the module of the same name. See Finding a repository for a module path for information on how the go command locates a repository using HTTP requests derived from a module path. If the module is not defined in the repository’s root directory, the module subdirectory is the part of the module path that names the directory, not including the major version suffix. This also serves as a prefix for semantic version tags. For example, the module golang.org/x/tools/gopls is in the gopls subdirectory of the repository with root path golang.org/x/tools, so it has the module subdirectory gopls. See Mapping versions to commits and Module directories within a repository. If the module is released at major version 2 or higher, the module path must end with a major version suffix like /v2. This may or may not be part of the subdirectory name. For example, the module with path golang.org/x/repo/sub/v2 could be in the /sub or /sub/v2 subdirectory of the repository golang.org/x/repo. If a module might be depended on by other modules, these rules must be followed so that the go command can find and download the module. There are also several lexical restrictions on characters allowed in module paths.