A Go version such as v4.1.2+incompatible is a release at major version 2 or higher from a repository that has no go.mod file. The suffix tells the go command it belongs to the same module as the lower major versions, so a plain upgrade may jump to a higher major version and break the build.
Where the suffix comes from
The Go Modules Reference explains the background. A module released at major version 2 or higher must carry a matching major version suffix in its path, for example /v2. That rule arrived with module support, by which time many repositories had already tagged releases at v2 or above without a go.mod.
To stay compatible with them, the go command appends +incompatible to versions at major version 2 or higher that lack a go.mod. The reference says this marks the version as part of the same module as the versions with lower major numbers. A requirement like require example.com/m v4.1.2+incompatible points at the semantic version tag v4.1.2 in the repository that provides example.com/m.
What it changes in practice
| Aspect | Normal v2 or higher module | +incompatible version |
|---|---|---|
| Module path | Ends with /v2, /v3 and so on | No major version suffix |
| Separate module per major | Yes, they can coexist as distinct modules | No, same module as lower majors |
| Upgrade behaviour | Major bump needs a new import path | The go command may upgrade to a higher incompatible version automatically |
The last row is the one with consequences. The reference states that the go command may automatically upgrade to higher +incompatible versions even though doing so may break the build. In a dependency update workflow, a bot or a routine upgrade can propose a major version move that looks like a minor change.
What it means for vulnerability scanning
Advisory data for Go identifies a module by path and affected version ranges. A dependency recorded as v4.1.2+incompatible has a version string that includes the suffix. A scanner has to decide how to compare it with ranges written as v4.1.2, or with ranges that stop at v4.1.1.
You cannot tell from the suffix alone whether a tool handles this well, so test it. Pick a module in your build with the suffix, find a published advisory for it if one exists, and see whether your tool reports it with the right version. The Go reference also notes that build metadata is ignored when comparing versions, which is a related rule worth knowing but not the same thing as the incompatible suffix.
Steps for your own project
- Search go.mod and go.sum for the string +incompatible.
- For each match, check whether the project has since added a go.mod and published a proper /v2 path.
- Pin the version you tested and review any update that moves the major number.
- Run your scanner and confirm those modules appear with the version you expect.
- Record the exact string, suffix included, in your SBOM.
When to worry
Most projects have only a few of these. Treat them as dependencies that deserve a manual look, because the module system gives them fewer guard rails than a normal versioned path. If one is abandoned, a major version jump with no go.mod is a good reason to look for an alternative or vendor a reviewed copy.
Safeguard's SBOM and dependency scanning records the versions your build resolves to, and the free scan can show you how a Go repository appears in an inventory.
Quick check
Is v2.0.0+incompatible the same as a /v2 module?
No. A /v2 module has its own path. The incompatible form has no path suffix and shares a module with lower major versions.
Can go get move me to a higher incompatible version?
The Go reference says the command may upgrade to higher incompatible versions automatically, even if that breaks the build, so review such updates.
Sources
Last reviewed: 19 October 2026.
