Run go list -m -u all in your module. It checks every module in the build list for deprecation notices and marks them, for example with the word deprecated after the version. The marker comes from a Deprecated comment the author wrote in that module's go.mod file.
How authors mark a module
The Go modules reference says a module is deprecated by a comment containing Deprecated:, case sensitive, at the start of a paragraph. It sits above the module directive or on the same line:
// Deprecated: use example.com/mod/v2 instead.
module example.com/mod
The message runs from the colon to the end of the paragraph. Authors usually name a replacement, so the text itself is often your migration hint.
What the marker covers
Three details change how you read it:
- A deprecation applies to all minor versions of a module.
- Major versions v2 and above are separate modules, so a v1 deprecation does not cover v2. That is often the point: the notice says to move to v2.
- You cannot deprecate a single minor or patch version. For that, authors use the retract directive instead.
How to check your project
- Run
go list -m -u alland scan the output for the word deprecated. - Filter for just those lines in CI so the build can fail or warn:
go list -m -u all | grep -i deprecated
- Remember that
go getalso warns when you fetch a deprecated module, but only for modules needed to build the packages named on the command line. It will not sweep your whole tree. - For each hit, read the message. If it names a replacement, plan the switch. If it gives no reason, look at the repository.
A deprecation is not a vulnerability report. The module may work fine today. What changes is that the author has told you no one is expected to keep improving it, so future security fixes are unlikely. Pair this check with a vulnerability scan.
Deprecated or retracted
| Notice | Scope | Typical reason |
|---|---|---|
| Deprecated comment | Whole module, all minor versions | Superseded or no longer maintained |
| Retract directive | Specific versions | Published by mistake or severely broken |
Retracted versions are not upgraded to automatically, and builds that already depend on them keep working. Deprecated modules also keep working. In both cases the notice is information, not enforcement, so you have to add the enforcement.
Turning the signal into a policy
Decide up front what happens on a hit. A simple rule works: a deprecated direct dependency opens a ticket with an owner and a review date, and a deprecated indirect dependency is checked for which direct module pulls it in. If you vendor or fork, record why.
Quick check
Does go get warn about all deprecated modules in my project?
No. It checks deprecated modules needed to build the packages named on the command line. Use go list -m -u all for the full build list.
If a v1 module is deprecated, is v2 deprecated too?
No. Major versions v2 and above are separate modules, so the deprecation does not cover them.
Safeguard's SBOM and dependency scanning inventories your dependencies and flags known vulnerabilities, which you can read next to deprecation notices. Try the free scan.
Sources
Last reviewed: 19 October 2026.
