63. Modules and releases: MVS, private modules, versioning, binaries

63.1 Minimal version selection, practically

Go modules use minimal version selection: builds use the minimum module versions required by your dependency graph, not necessarily the newest available versions.

go list -m all
go mod graph
go mod why -m github.com/some/dependency
go get github.com/acme/lib@v1.4.2
go mod tidy

This makes builds reproducible, but it also means dependency bumps should be deliberate and reviewed like code.

63.2 Private modules

go env -w GOPRIVATE=github.com/mycompany/*
go env -w GONOSUMDB=github.com/mycompany/*

GOPRIVATE tells the Go command not to use the public checksum database or module proxy for matching paths. Without it, private import paths may leak to public infrastructure during module resolution.

63.3 Semantic import versioning

Public module v2+ paths include the major version:

module github.com/acme/client/v2

Callers import:

import "github.com/acme/client/v2"

If you do not want a /v2, avoid breaking exported APIs. Add new functions and options instead of changing old signatures.

63.4 Build metadata and repeatable releases

go build -trimpath \
  -ldflags "-s -w -X main.version=$VERSION -X main.commit=$COMMIT -X main.date=$DATE" \
  -o dist/myapp ./cmd/myapp

var (
	version = "dev"
	commit  = "none"
	date    = "unknown"
)

Expose this in myapp version and logs. During an incident, "which commit is running?" should be answerable in seconds.

63.5 Release checklist

• Tag source (v1.2.3).
• Build from a clean tree in CI.
• Run tests, race tests where feasible, linters, and govulncheck.
• Produce checksums for artifacts.
• Sign artifacts if your users install them directly.
• Publish release notes with breaking changes, migrations, and known issues.

Tools like GoReleaser are useful because they encode this checklist.