DEV Community

Cover image for The Go Dependency Blindspot: Why You’re Missing Major Upgrades (and How to Fix It)
Chiman Jain
Chiman Jain

Posted on

The Go Dependency Blindspot: Why You’re Missing Major Upgrades (and How to Fix It)

#go #cicd #productivity #opensource

Go’s module system is widely celebrated for its predictability, speed, and reproducibility. Through the implementation of Semantic Import Versioning (SIV), the Go compiler guarantees that your builds remain stable and immune to dependency conflicts. It does this by treating different major versions (e.g., /v2, /v3, /v4) as entirely distinct packages.

However, this design introduces a silent but massive developer workflow blindspot.

If you rely solely on standard commands like go list -m -u all to keep your Go packages up-to-date, you are completely missing major upgrades. Because a major version upgrade changes the module import path itself, Go's default tooling has no native way to tell you that a package you rely on has published a brand-new major release.

In this post, we’ll explore the mechanics behind this dependency blindspot, look at the risks of silent version decay, and show you how to solve it instantly using GoMajor—a fast, zero-dependency CLI tool built to proactively scan and report Go dependency upgrades.

The Root Cause: Semantic Import Versioning

To understand why this blindspot exists, we have to look at how Go handles package naming.

In most package managers (like npm, cargo, or pip), a major version bump updates the package version but keeps the package name identical. In Go, semantic versioning is tied directly to the import path. When a library introduces breaking changes and bumps its major version, it must update its path:

// Importing v1 of a package (implicit)
import "github.com/go-chi/chi"

// Importing v5 of the same package (explicit)
import "github.com/go-chi/chi/v5"
Enter fullscreen mode Exit fullscreen mode

To the Go compiler, github.com/go-chi/chi and github.com/go-chi/chi/v5 are not the same library; they are completely independent modules.

Because of this separation, go list -m -u all only checks for minor updates and patch releases within the import path currently defined in your go.mod file. If your project imports github.com/foo/bar (v1), go list will query the Go Module Proxy for new v1.x.x releases. It will never look for github.com/foo/bar/v2 or github.com/foo/bar/v3.

The Danger of Silent Version Decay

Without proactive monitoring, your codebase falls victim to "silent version decay." This leads to several long-term development issues:

  1. Missing Modern Language Features: Many popular Go libraries have undergone massive rewrites in recent major versions to utilize Go generics (introduced in Go 1.18), improved standard library interfaces (like io/fs or structured logging with slog), or new synchronization patterns. By remaining stuck on older major versions, your team misses out on writing idiomatic, modern Go.
  2. Security Vulnerabilities (CVEs): While security fixes are sometimes backported to older major versions, maintenance eventually stops. If a critical vulnerability is discovered in an old major version, the maintainers will require you to upgrade to the latest major version to get the fix.
  3. The "Upgrade Tax": The longer you defer a major upgrade, the harder it becomes. Skipping from v1 to v5 all at once is significantly more painful than upgrading incrementally.

The Solution: GoMajor

GoMajor is a CLI tool written in Go that closes the dependency upgrade gap.

Instead of wrapping the local go binary, GoMajor parses your go.mod file directly and queries the official Go Module Proxy (https://proxy.golang.org) in real-time. It maps your current packages, escapes the paths according to Go's module proxy specifications, and sequentially probes for higher major versions (e.g., checking for /v2, /v3, /v4 on the proxy).

By default, it flags both minor updates (🟢 Green) and major upgrades (🟡 Yellow), giving you a complete overview of your codebase's health.

Comprehensive Output Formats for Developers and Pipelines

GoMajor is designed to fit seamlessly into any developer's workflow, offering visual CLI reports for active development and structured data exports for automation.

1. Terminal Output (Default)

When run locally, GoMajor displays a clean, color-coded table in the terminal. It aligns your current version side-by-side with discovered minor and major updates, and provides the exact new import path required to make the upgrade.

https://raw.githubusercontent.com/spf13/cobra/main/go.mod (github)
  MODULE               CURRENT   MINOR     MAJOR         NEW PATH
  go.yaml.in/yaml/v3   v3.0.4    -         v4.0.0-rc.4   go.yaml.in/yaml/v4
Enter fullscreen mode Exit fullscreen mode

2. Structured JSON Output

For teams that want to feed dependency audits into downstream tools, dashboards, or custom alerting systems, GoMajor outputs structured JSON:

{
  "results": [
    {
      "source": "https://raw.githubusercontent.com/spf13/cobra/main/go.mod",
      "source_type": "github",
      "dependencies": [
        {
          "module": "go.yaml.in/yaml/v3",
          "current_version": "v3.0.4",
          "latest_major_version": "v4.0.0-rc.4",
          "latest_major_path": "go.yaml.in/yaml/v4",
          "has_update": true
        }
      ]
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

3. YAML Report Format

If your team uses YAML-based reports or wants to output documentation that integrates easily with infrastructure configurations, GoMajor fully supports native YAML formatting:

results:
  - source: https://raw.githubusercontent.com/spf13/cobra/main/go.mod
    source_type: github
    dependencies:
      - module: go.yaml.in/yaml/v3
        current_version: v3.0.4
        latest_major_version: v4.0.0-rc.4
        latest_major_path: go.yaml.in/yaml/v4
        has_update: true
Enter fullscreen mode Exit fullscreen mode

Power-User CLI Features

Installing GoMajor is a single command:

go install github.com/chimanjain/gomajor@latest
Enter fullscreen mode Exit fullscreen mode

Once installed, you can leverage GoMajor's flexible flags to tailor the tool to your environment:

Remote Repository Auditing

One of GoMajor's most powerful features is remote scanning. If you want to check the dependency health of a third-party library or audit a public repository before importing it into your codebase, you can scan it directly from GitHub without cloning it locally:

# Check dependencies of a remote repository directly
gomajor -g owner/repo
Enter fullscreen mode Exit fullscreen mode

Advanced Filtering and Probing Flags

  • Deep Probing (-m, --max-probe): By default, GoMajor looks up to 5 major versions ahead of your current version. If you are tracking libraries with long version histories, you can expand this search window: 
  gomajor --max-probe=10
Enter fullscreen mode Exit fullscreen mode
  • Include Indirect Dependencies (-a, --all): By default, GoMajor focuses on direct dependencies. Turn on indirect scanning to audit your complete dependency tree: 
  gomajor --all
Enter fullscreen mode Exit fullscreen mode
  • Filter Update Types: Toggle minor updates or major upgrades off to isolate specific tasks: 
  # Only search for major version bumps
  gomajor --minor=false

  # Only search for minor/patch updates
  gomajor --major=false
Enter fullscreen mode Exit fullscreen mode

Workflow Integration: Multi-Source Configs and CI/CD

Managing dependencies across multiple repositories or microservices can quickly become overwhelming. GoMajor addresses this by supporting unified multi-source configurations through a gomajor.yaml file:

local:
  - "./gateway-service/go.mod"
  - "./auth-service/go.mod"
github:
  - "my-org/shared-utils-library"
output: "dependency-audit.json"
minor: true
major: true
Enter fullscreen mode Exit fullscreen mode

Running gomajor in the directory containing this config will execute concurrent checks across all specified local and remote sources, compile the findings, and write the consolidated results into dependency-audit.json.

Integrating into GitHub Actions

You can easily incorporate GoMajor into your CI pipelines to enforce dependency cleanliness. Here is an example of a simple GitHub Actions workflow that runs a dependency check on every pull request:

name: GoMajor Dependency Audit
permissions:
  contents: read
on:
  pull_request:
    branches: [main]

jobs:
  gomajor-dependency-audit:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Code
        uses: actions/checkout@v6

      - name: Set up Go
        uses: actions/setup-go@v6
        with:
          go-version: "1.26"

      - name: Install GoMajor
        run: go install github.com/chimanjain/gomajor@latest

      - name: Run Dependency Audit
        run: gomajor
Enter fullscreen mode Exit fullscreen mode

Conclusion

Go’s module architecture keeps builds stable, but stable shouldn't mean static. Keeping dependencies current avoids the technical debt of massive, multi-version upgrades down the road.

GoMajor takes the manual work out of dependency tracking, making major upgrade discovery automatic, visual, and CI/CD-ready. Give it a try, add it to your pipeline, and make sure your projects aren't left behind.

👉 Check out the project, view the source, and star/contribute on GitHub: github.com/chimanjain/gomajor

Top comments (0)