A version identifies a release of a Go module. It gives consumers a specific dependency to select and communicates what kinds of changes they can expect when they upgrade. In a repository with multiple modules, each module has its own version history rather than sharing one release number. section 11.2 section 11.3.5
Go module releases use semantic versions in the form vMAJOR.MINOR.PATCH:
- Increment MAJOR for an incompatible API change. section 11.2
- Increment MINOR for backward-compatible functionality. section 11.2
- Increment PATCH for a backward-compatible bug fix. section 11.2
For a module in a multimodule repository, prefix its Git release tag with the module path: domain/v0.0.1 identifies a release of domain, while storage/v0.0.1 identifies a separate release of storage. A consumer can then select a release in go.mod, such as github.com/YOUR_USERNAME/go-news/domain v0.0.1. section 11.2
cd domain git add . git commit -m "Initial domain module with core entities and interfaces" git tag domain/v0.0.1 git push origin domain/v0.0.1
The commit and tag commands show how a domain module receives and publishes its first module-specific release tag. section 11.2
Release only what changed
An API can move to api/v1.1.0 and a worker to worker/v1.1.0 while domain stays at domain/v0.0.1. If domain later makes a breaking change and moves to v2.0.0, the API and worker must update their go.mod dependencies to adopt it. Version numbers in logs and monitoring also help locate a problematic release and support a rollback. section 11.3.5
