Release Pipeline

[serdarozerr]

Context

In the original repositories, each storage CLI had its own release pipeline responsible for tagging, creating releases, and uploading artifacts to an S3 bucket.

Solution

We introduced a unified release pipeline that runs unit tests as a sanity check and then performs the following steps in order:

• Bumps the version according to the defined logic
• Generates the changelog
• Builds the source code for Linux and Windows
• Publishes the release on GitHub

Release Versioning

Version Bump Rules:

• feat: - New feature → Minor version bump (v1.2.0 → v1.3.0)
• BREAKING CHANGE: - Breaking changes → Major version bump (v1.2.0 → v2.0.0)
• Patch version bump (v1.2.0 → v1.2.1)
  • fix: - Bug fix
  • docs: - Documentation changes
  • chore: - Maintenance tasks (dependencies, build config, tooling)
  • refactor: - Code restructuring without behavior changes
  • test: - Test updates
  • style: - Formatting and whitespace
  • ci: - CI/CD configuration changes
  • perf: - Performance improvements
  • build: - Dependabot commits
  • no conventional commits - text without specifying any of above

Commit Message Examples

# Patch release (v1.2.3 → v1.2.4)
git commit -m "fix: resolve upload timeout issue"

# Minor release (v1.2.3 → v1.3.0)
git commit -m "feat: add retry logic for failed uploads"

# Major release (v1.2.3 → v2.0.0)
git commit -m "feat: redesign upload API

BREAKING CHANGE: Upload() signature changed to return structured error"

# No release
git commit -m "docs: update Azure Blob Storage usage examples"
git commit -m "chore: upgrade dependencies"

[stephanme]

Do we really want to have a release per commit?
At least now when storage-cli is still under heavy development, this is maybe a bit too much noise.

I would start with manual releases and later e.g. weekly releases.