Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
113 changes: 113 additions & 0 deletions .github/RELEASE_TEMPLATE.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,113 @@
# Release Template

Use this template when preparing a new release.

## Pre-Release Checklist

- [ ] Update version number in relevant files
- [ ] Update CHANGELOG.md with new version
- [ ] Run full test suite: `go test ./...`
- [ ] Run linter: `golangci-lint run`
- [ ] Build for all platforms: `make build-all`
- [ ] Test the `ccp` wrapper locally
- [ ] Update documentation if needed

## CHANGELOG.md Template

```markdown
## [X.Y.Z] - YYYY-MM-DD

### Added
- New feature description

### Changed
- Changed feature description

### Fixed
- Bug fix description

### Removed
- Removed feature description

### Security
- Security fix description
```

## Creating the Release

### 1. Update CHANGELOG.md
Move items from `[Unreleased]` section to new version section:

```bash
# Example for v1.2.0
vim CHANGELOG.md
# Move unreleased changes to new [1.2.0] section
# Add release date
```

### 2. Commit the changelog
```bash
git add CHANGELOG.md
git commit -m "docs: Update CHANGELOG for v1.2.0"
git push
```

### 3. Create Git Tag
```bash
git tag -a v1.2.0 -m "Release v1.2.0: Brief description"
git push origin v1.2.0
```

### 4. Create GitHub Release
```bash
gh release create v1.2.0 \
--title "v1.2.0 - Release Title" \
--notes-file <(sed -n '/## \[1.2.0\]/,/## \[/p' CHANGELOG.md | head -n -1)
```

Or manually via GitHub UI:
1. Go to https://github.com/nielspeter/claude-code-proxy/releases/new
2. Select tag: `v1.2.0`
3. Copy release notes from CHANGELOG.md
4. Publish release

## Semantic Versioning Guidelines

- **MAJOR** (X.0.0): Breaking changes, incompatible API changes
- **MINOR** (1.X.0): New features, backward-compatible
- **PATCH** (1.1.X): Bug fixes, backward-compatible

### Examples

- `v1.2.0`: Added new model provider support βœ… MINOR
- `v1.1.1`: Fixed streaming bug βœ… PATCH
- `v2.0.0`: Changed config file format (breaking) βœ… MAJOR

## Conventional Commits

Use these prefixes for commits (helps with changelog generation):

- `feat:` - New feature (MINOR version bump)
- `fix:` - Bug fix (PATCH version bump)
- `docs:` - Documentation only
- `refactor:` - Code refactoring
- `test:` - Adding tests
- `chore:` - Maintenance tasks
- `perf:` - Performance improvements
- `ci:` - CI/CD changes

### Examples
```bash
feat: Add support for Azure OpenAI provider
fix: Resolve streaming token count issue
docs: Update installation instructions
test: Add unit tests for model detection
```

## Post-Release Tasks

- [ ] Verify release appears on GitHub
- [ ] Test installation from release binaries
- [ ] Announce release (if applicable)
- [ ] Update any dependent projects
- [ ] Start new `[Unreleased]` section in CHANGELOG.md
201 changes: 201 additions & 0 deletions .github/RELEASE_WORKFLOW.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,201 @@
# Release Workflow Guide

This guide explains how to create releases for claude-code-proxy.

## Files Created

1. **`CHANGELOG.md`** - Main changelog following [Keep a Changelog](https://keepachangelog.com/) format
2. **`.github/RELEASE_TEMPLATE.md`** - Template and checklist for creating releases
3. **`.github/workflows/release.yml`** - Automated GitHub Actions workflow (updated)

## Quick Release Process

### 1. Update CHANGELOG.md

Before creating a release, move unreleased changes to a new version section:

```bash
# Edit CHANGELOG.md
vim CHANGELOG.md
```

Change:
```markdown
## [Unreleased]
### Added
- New feature X
- New feature Y
```

To:
```markdown
## [Unreleased]

## [1.2.0] - 2025-11-02
### Added
- New feature X
- New feature Y
```

### 2. Commit and Push

```bash
git add CHANGELOG.md
git commit -m "docs: Update CHANGELOG for v1.2.0"
git push
```

### 3. Create and Push Tag

```bash
git tag -a v1.2.0 -m "Release v1.2.0: Brief description"
git push origin v1.2.0
```

### 4. Automated Release

The GitHub Action will automatically:
- βœ… Run all tests
- βœ… Build binaries for all platforms (Linux, macOS, Windows, ARM, x86)
- βœ… Create checksums
- βœ… Extract release notes from CHANGELOG.md
- βœ… Create GitHub release with installation instructions
- βœ… Upload all binaries to the release

## What the Workflow Does

### If CHANGELOG.md has section for this version:
1. Extracts your curated changelog content
2. Appends installation instructions
3. Uses your changelog as release notes

### If no CHANGELOG.md section found:
1. Falls back to auto-generated release notes from PRs
2. Adds installation instructions

## Example CHANGELOG.md Structure

```markdown
# Changelog

## [Unreleased]
### Added
- Feature still in development

## [1.2.0] - 2025-11-02
### Added
- Dynamic model detection from provider API
- Support for new reasoning models

### Fixed
- Token counting issue in streaming mode

### Changed
- Improved error handling

## [1.1.0] - 2025-10-31
### Added
- Reasoning model support

## [1.0.0] - 2025-10-26
### Added
- Initial release
```

## Conventional Commits (Recommended)

Using conventional commits makes it easier to categorize changes:

```bash
# Features (go in "Added" section)
git commit -m "feat: Add support for Azure OpenAI"

# Bug fixes (go in "Fixed" section)
git commit -m "fix: Resolve streaming timeout issue"

# Documentation (go in "Changed" section if user-facing)
git commit -m "docs: Update installation guide"

# Tests (usually not in changelog)
git commit -m "test: Add unit tests for model detection"

# Refactoring (go in "Changed" if user-facing)
git commit -m "refactor: Simplify config loading"
```

## Versioning Strategy

Follow [Semantic Versioning](https://semver.org/):

- **MAJOR** (2.0.0): Breaking changes
- Example: Changed config file format
- Example: Removed deprecated API

- **MINOR** (1.X.0): New features, backward-compatible
- Example: Added support for new provider
- Example: Added new CLI flag

- **PATCH** (1.1.X): Bug fixes, backward-compatible
- Example: Fixed token counting bug
- Example: Fixed crash on startup

## Troubleshooting

### Release workflow failed?

Check:
1. Did you run `make build-all` locally first to verify builds work?
2. Did you update CHANGELOG.md with the version number?
3. Did the tag format match `v*.*.*` (e.g., `v1.2.0` not `1.2.0`)?

### Release notes look wrong?

1. Check that CHANGELOG.md has a section `## [1.2.0]` matching your tag `v1.2.0`
2. The section should be between the version heading and the next version heading
3. Make sure there's proper markdown formatting

### Want to test locally?

```bash
# Test changelog extraction
VERSION="1.2.0"
sed -n "/## \[${VERSION}\]/,/## \[/p" CHANGELOG.md | sed '$d' | tail -n +2

# Test builds
make build-all
cd dist && sha256sum * > checksums.txt
```

## Manual Release (if needed)

If you need to create a release manually:

```bash
# Create release via GitHub CLI
gh release create v1.2.0 \
--title "v1.2.0 - Release Title" \
--notes "$(sed -n '/## \[1.2.0\]/,/## \[/p' CHANGELOG.md | sed '$d' | tail -n +2)" \
dist/*
```

Or use the GitHub web interface:
1. Go to: https://github.com/nielspeter/claude-code-proxy/releases/new
2. Choose tag: `v1.2.0`
3. Copy content from CHANGELOG.md for that version
4. Upload binaries from `dist/` folder
5. Publish

## Tips

1. **Keep Unreleased section active**: Always have an `[Unreleased]` section at the top for ongoing work
2. **Update CHANGELOG as you go**: Don't wait until release time to document changes
3. **Link to issues/PRs**: Add links like `(#123)` for context
4. **Be concise**: Focus on user-facing changes, not internal refactoring (unless significant)
5. **Test first**: Always run tests and build locally before tagging

## Questions?

See:
- `.github/RELEASE_TEMPLATE.md` for detailed checklist
- `CHANGELOG.md` for examples of good changelog entries
- [Keep a Changelog](https://keepachangelog.com/) for format guidelines
Loading
Loading