Skip to content

Latest commit

 

History

History
126 lines (100 loc) · 2.93 KB

File metadata and controls

126 lines (100 loc) · 2.93 KB

Release Checklist

Use this checklist for every release. All items must be completed before publishing.

Pre-Release

Code Quality

  • All tests pass: go test ./...
  • Linting passes: make lint
  • Formatting is clean: gofmt -l . returns nothing
  • Security scan passes: gosec ./...
  • No TODOs or FIXMEs in release-critical code
  • Dependencies are up to date: go list -u -m all

Documentation

  • CHANGELOG.md updated with version and changes
  • VERSION in version.go matches release tag
  • API documentation is current
  • MIGRATION.md updated if breaking changes
  • Docs build successfully

Build Verification

  • Clean build succeeds: go build ./...
  • Cross-platform builds pass
  • Binary artifacts build correctly
  • Docker images build successfully
  • Checksums match across builds

Release Assets

  • Source tarball created
  • Binaries built for all platforms
  • SHA256SUMS file generated
  • Optional: GPG signature created
  • Release notes drafted

Creating the Release

1. Version Bump

# Update version in version.go
# Update CHANGELOG.md
# Commit changes
git add internal/version/version.go CHANGELOG.md
git commit -m "chore: prepare for v0.1.0"

2. Create Tag

# Create signed tag
git tag -s v0.1.0 -m "Release v0.1.0"

# Verify tag
git tag -v v0.1.0

# Push tag
git push origin v0.1.0

3. Build Release Artifacts

# Run release build
make release

# Verify checksums
sha256sum -c SHA256SUMS

4. Create GitHub Release

# Using gh CLI
gh release create v0.1.0 \
  --title "v0.1.0" \
  --notes-file RELEASE_NOTES.md \
  lattice-*.tar.gz \
  SHA256SUMS

Post-Release

Verification

  • GitHub release published
  • Assets downloadable and verify
  • Go module proxy has indexed (check pkg.go.dev)
  • Docker images available
  • CI/CD passes on tag

Announcements

  • GitHub discussion created
  • Release notes tweeted/posted
  • Changelog updated on website
  • Users notified of breaking changes

Emergency Rollback

If critical issues are found:

For Go Modules

  1. Yank the version on GitHub (delete release, keep tag)
  2. Publish v0.1.1 with fix immediately
  3. Users can pin to working version

For Docker Images

  1. Delete image tag from registry
  2. Push corrected image
  3. Update latest tag

Recovery Time Target: < 4 hours

Version Policy

Semantic Versioning

  • MAJOR: Breaking changes to API or storage format
  • MINOR: New features, backward compatible
  • PATCH: Bug fixes, backward compatible

Pre-Release Versions

  • Format: v0.1.0-alpha.1, v0.1.0-beta.1, v0.1.0-rc.1
  • Alpha: Early development, unstable
  • Beta: Feature complete, testing needed
  • RC: Release candidate, only fixes allowed

Deprecation Process

  1. Mark as deprecated in documentation
  2. Add compiler warning if applicable
  3. Maintain for 2 minor versions
  4. Remove in next major version