Pin an exact version for any Go tool you rely on, and use the latest suffix only when you deliberately want whatever is newest today. Per the Go documentation, a version suffix makes go install ignore the go.mod file in your current directory, so the suffix alone decides what you get.
What the suffix changes
The Go team's note on deprecating go get for installs describes two modes.
- Without a version suffix, go install installs an executable in the context of the current module. It applies version requirements and other directives from the go.mod file in the current directory or a parent.
- With a version suffix such as @v1.2.3 or @latest, go install ignores the current module. The documentation says it does not read or update go.mod in the current directory or any parent.
It also gives examples: a specific version with @v1.2.3, and the highest available version with @latest. When a suffix is used, all arguments must refer to main packages in the same module at the same version.
What each choice means for safety
| Choice | You get | Risk to think about |
|---|---|---|
| @v1.2.3 | The same code each time, assuming that version is not changed | You may miss fixes until you bump it |
| @latest | The highest available version at install time | A new release, good or bad, arrives without review |
| No suffix | The version your module requires | Depends on go.mod being reviewed |
Latest is convenient and also unrepeatable. Two engineers running it a week apart can have different tools. A pinned version is repeatable, which also makes an incident easier to investigate: you can say exactly which version ran.
Pin it in the project, not in a wiki
If a tool is part of your build, writing a version in a README invites drift. Go has a way to record tool dependencies in go.mod, covered in the go tool directive. Teams that want a single place to hold runtime and tool versions can also read pinning runtime and SDK versions.
Updating on purpose
A pin is not forever. Treat it like any dependency.
- Put a reminder to review tool versions on a regular schedule.
- When you bump, read the release notes and check the module's maintainers.
- Install the new pinned version and run your usual checks.
- Record the change in version control.
Where the binary lands
Go installs executables into a bin folder, and you add that folder to your PATH. Confirm it is a folder you own, and review what is in it occasionally, as with any global tools directory. The inventory post lists commands for several ecosystems.
Example team policy
A short written rule avoids arguments later. For instance: tools used in CI are pinned to an exact version in the repository. Tools used only on a laptop may use the latest suffix, but the engineer notes the resolved version in the pull request when the tool changes the code, such as a generator or formatter. Anything that touches release artifacts is always pinned.
Writing it down also helps new joiners, who otherwise copy whatever command they find in an old chat message.
Quick check
Does go install with @latest read my go.mod?
No. With a version suffix it does not read or update go.mod in the current directory or a parent.
Why prefer a pinned version for shared tools?
Everyone gets the same code, and an incident review can say exactly which version ran.
Sources
Last reviewed: 19 October 2026.
