Structured releases ensure predictable deployments and clear communication of changes.
We follow Semantic Versioning (✧ SemVer):
MAJOR.MINOR.PATCH → 1.2.3
| Segment | Bumps When... | Examples |
|---|---|---|
| MAJOR | Breaking API change | 1.0.0 → 2.0.0 |
| MINOR | Back‑compatible feature / enhancement | 1.2.0 → 1.3.0 |
| PATCH | Back‑compatible bug fix / docs | 1.2.3 → 1.2.4 |
- Releases are driven by goreleaser and configured in
.goreleaser.yml. - Install locally with Homebrew (Mac):
brew install goreleaser| Step | Command | Purpose |
|---|---|---|
| 1 | magex release:snapshot |
Build & upload a snapshot (pre‑release) for quick CI validation. |
| 2 | magex version:bump push=true bump=patch |
Create and push a signed Git tag. Triggers GitHub Actions to package the release |
| 3 | GitHub Actions | CI runs goreleaser release on the tag; artifacts and changelog are published to GitHub Releases. |
Note for AI Agents: Do not create or push tags automatically. Only the repository codeowners are authorized to tag and publish official releases.
GoReleaser automatically generates changelogs from commit messages:
- Groups commits by type (
feat,fix,docs, etc.) - Excludes certain commit types (configured in
.goreleaser.yml) - Links to PRs and issues mentioned in commits
For significant releases, you may want to add a manual summary:
- Create a draft release on GitHub
- Edit the auto-generated changelog
- Add a "Highlights" section at the top
- Call out breaking changes prominently
- Release tags:
v1.2.3(always prefix withv) - Pre-release tags:
v1.2.3-rc.1,v1.2.3-beta.2 - Development snapshots: Generated automatically, not tagged
GoReleaser produces:
- Binaries for multiple platforms (Linux, macOS, Windows)
- Docker images (if configured)
- Checksums for verification
- Release notes from commits
- Source archives (tar.gz, zip)
All artifacts are automatically uploaded to GitHub Releases.
Before tagging a release:
- All linters passing (
magex lint) - All tests passing (
magex test) - No security vulnerabilities (
magex deps:audit) - Documentation updated
- Version bumped if needed
- PR merged to main branch
For critical production fixes:
- Create branch from the release tag:
git checkout -b hotfix/security-fix v1.2.3 - Apply minimal fix
- Test thoroughly
- Tag as patch:
v1.2.4 - Cherry-pick to main branch
- Document in release notes
Check release history:
# List all tags
git tag -l
# Show specific release info
git show v1.2.3
# Compare versions
git log v1.2.2..v1.2.3 --onelineThe release process is largely automated via GitHub Actions:
- Trigger: Push of a tag matching
v* - Workflow:
.github/workflows/fortress-release.yml - Configuration:
.goreleaser.yml - Permissions: Requires
GITHUB_TOKENwith release permissions
Manual intervention should rarely be needed. If issues arise, check the Actions tab.