|
| 1 | +# Release Checklist |
| 2 | + |
| 3 | +Use this checklist when preparing a manual release. |
| 4 | + |
| 5 | +## Pre-Release Checks |
| 6 | + |
| 7 | +### Code Quality |
| 8 | +- [ ] All tests pass locally (`uv run pytest src/tests/`) |
| 9 | +- [ ] Linting passes (`uv run ruff check .`) |
| 10 | +- [ ] Formatting is consistent (`uv run ruff format --check .`) |
| 11 | +- [ ] Type checking passes (`uv run mypy src/`) |
| 12 | +- [ ] Pre-commit hooks pass (`uv run pre-commit run --all-files`) |
| 13 | + |
| 14 | +### Documentation |
| 15 | +- [ ] README.md is up to date |
| 16 | +- [ ] CHANGELOG.md has unreleased changes documented |
| 17 | +- [ ] API documentation is current |
| 18 | +- [ ] Version-specific documentation is ready |
| 19 | + |
| 20 | +### Dependencies |
| 21 | +- [ ] Dependencies are up to date (`uv sync`) |
| 22 | +- [ ] Security vulnerabilities checked (`uv run safety check`) |
| 23 | +- [ ] License compliance verified |
| 24 | + |
| 25 | +### Environment Testing |
| 26 | +- [ ] Docker build succeeds (`docker compose build`) |
| 27 | +- [ ] Docker containers start successfully (`docker compose up -d`) |
| 28 | +- [ ] Health checks pass (`make health-check`) |
| 29 | +- [ ] Integration tests pass |
| 30 | + |
| 31 | +## Release Process |
| 32 | + |
| 33 | +### 1. Version Planning |
| 34 | +- [ ] Determine version type (major/minor/patch) |
| 35 | +- [ ] Review breaking changes (if major version) |
| 36 | +- [ ] Plan migration path (if needed) |
| 37 | + |
| 38 | +### 2. Version Bump |
| 39 | +Choose one method: |
| 40 | + |
| 41 | +**Automatic (recommended):** |
| 42 | +```bash |
| 43 | +make bump-patch # or bump-minor, bump-major |
| 44 | +``` |
| 45 | + |
| 46 | +**Manual:** |
| 47 | +- [ ] Update version in `pyproject.toml` |
| 48 | +- [ ] Update CHANGELOG.md with new version |
| 49 | +- [ ] Commit changes: `git commit -m "Bump version to X.Y.Z"` |
| 50 | +- [ ] Create tag: `git tag -a "vX.Y.Z" -m "Release X.Y.Z"` |
| 51 | +- [ ] Push: `git push && git push --tags` |
| 52 | + |
| 53 | +### 3. GitHub Release |
| 54 | +The release workflow will automatically: |
| 55 | +- [ ] Run complete test suite |
| 56 | +- [ ] Build Python packages |
| 57 | +- [ ] Build and push Docker images |
| 58 | +- [ ] Create GitHub release with notes |
| 59 | +- [ ] Publish to container registry |
| 60 | + |
| 61 | +### 4. Post-Release Verification |
| 62 | +- [ ] GitHub release created successfully |
| 63 | +- [ ] Docker images available (`ghcr.io/owner/repo:version`) |
| 64 | +- [ ] Release notes are accurate |
| 65 | +- [ ] Download links work |
| 66 | +- [ ] Documentation updated (if needed) |
| 67 | + |
| 68 | +### 5. Communication |
| 69 | +- [ ] Announce on relevant channels |
| 70 | +- [ ] Update any dependent projects |
| 71 | +- [ ] Close related issues/milestones |
| 72 | + |
| 73 | +## Hotfix Releases |
| 74 | + |
| 75 | +For urgent fixes to production: |
| 76 | + |
| 77 | +1. **Create hotfix branch** from latest release tag: |
| 78 | + ```bash |
| 79 | + git checkout -b hotfix/vX.Y.Z+1 vX.Y.Z |
| 80 | + ``` |
| 81 | + |
| 82 | +2. **Apply minimal fix** and test thoroughly |
| 83 | + |
| 84 | +3. **Follow release process** with patch version bump |
| 85 | + |
| 86 | +4. **Merge back** to main branch: |
| 87 | + ```bash |
| 88 | + git checkout main |
| 89 | + git merge hotfix/vX.Y.Z+1 |
| 90 | + ``` |
| 91 | + |
| 92 | +## Rollback Procedure |
| 93 | + |
| 94 | +If a release has critical issues: |
| 95 | + |
| 96 | +1. **Immediate action:** |
| 97 | + - Mark GitHub release as pre-release |
| 98 | + - Update Docker tags to point to previous version |
| 99 | + |
| 100 | +2. **Create hotfix** following procedure above |
| 101 | + |
| 102 | +3. **Communicate** the rollback and timeline for fix |
| 103 | + |
| 104 | +## Version Naming Conventions |
| 105 | + |
| 106 | +- **Stable releases**: `vX.Y.Z` (e.g., v1.2.3) |
| 107 | +- **Pre-releases**: `vX.Y.Z-alpha.N`, `vX.Y.Z-beta.N`, `vX.Y.Z-rc.N` |
| 108 | +- **Development**: Use pre-release versions |
| 109 | + |
| 110 | +## Automation |
| 111 | + |
| 112 | +This project supports automated releases via conventional commits: |
| 113 | + |
| 114 | +- `feat: description` → Minor release |
| 115 | +- `fix: description` → Patch release |
| 116 | +- `feat!: description` → Major release |
| 117 | +- `BREAKING CHANGE: description` → Major release |
| 118 | + |
| 119 | +**Enable automated releases** by merging commits with conventional format to main branch. |
0 commit comments