Release Strategy

Overview

This document describes the release process for our project. We use semantic versioning with automated releases based on conventional commits.

Table of Contents

1. Version Numbering
2. Branch Strategy
3. Release Process
4. Commit Convention
5. Automated Releases

Version Numbering

We use semantic versioning (MAJOR.MINOR.PATCH) automatically calculated from commit messages:

• MAJOR version for breaking changes
• MINOR version for new features
• PATCH version for bug fixes

Branch Strategy

• main - Production code
• develop - Integration branch
• feature/* - New features
• fix/* - Bug fixes
• hotfix/* - Emergency fixes

Release Process

Releases are automated using semantic-release and triggered by merging to main:

1. Write commits following conventional commit format
2. Create PR to develop
3. Merge develop to main when ready to release
4. Automated process:
5. Calculates version
6. Creates changelog
7. Creates GitHub release
8. Tags Docker images

Commit Convention

Format: <type>(<scope>): <description>

Types: - feat: New feature (MINOR version) - fix: Bug fix (PATCH version) - feat! or BREAKING CHANGE: Breaking change (MAJOR version) - docs: Documentation only - style: Code style changes - refactor: Code refactoring - perf: Performance improvements - test: Adding/updating tests - chore: Maintenance tasks

Examples:

feat: add new user authentication endpoint
fix: resolve memory leak in worker process
feat!: redesign API response format

Automated Releases

Releases are handled by GitHub Actions workflow:

name: Release Workflow

on:
  push:
    branches:
      - main

jobs:
  github-release: ...
  docker-release: ...

For more details, see: - Contributing Guidelines