# Release Strategies Reference

This document provides detailed guidance on different release strategies and deployment targets.

## npm Package Release

**Best for**: JavaScript/TypeScript libraries, CLI tools, frameworks

**Prerequisites**:
- npm account and NPM_TOKEN secret configured
- `package.json` with correct metadata (name, version, main, types)
- Build output in publishable state

**Workflow steps**:
1. Build the package
2. Run `npm publish`
3. Create GitHub Release with version tag
4. Include link to npm package in release notes

**Configuration**:
```json
{
  "name": "@username/package-name",
  "version": "1.0.0",
  "main": "dist/index.js",
  "types": "dist/index.d.ts",
  "files": ["dist"],
  "scripts": {
    "build": "tsc",
    "prepublishOnly": "npm run build"
  }
}
```

**GitHub Release notes example**:
```
📦 Published to npm: https://www.npmjs.com/package/@username/package-name

Install with:
npm install @username/package-name
```

## GitHub Pages Deployment

**Best for**: Static websites, documentation sites, SPAs

**Prerequisites**:
- GitHub Pages enabled in repository settings
- Build outputs static files to a directory (usually `dist/` or `build/`)

**Workflow steps**:
1. Build the static site
2. Deploy to `gh-pages` branch using `peaceiris/actions-gh-pages`
3. Create GitHub Release with link to live site

**Configuration considerations**:
- Set correct `base` path for SPAs (e.g., Vite: `base: '/repo-name/'`)
- Configure 404.html for SPA routing
- Custom domain setup (optional)

**GitHub Release notes example**:
```
🌐 Deployed to: https://username.github.io/repo-name

Changes in this release:
[auto-generated release notes]
```

## Vercel Deployment

**Best for**: Next.js apps, React apps, modern web frameworks

**Prerequisites**:
- Vercel account connected to GitHub
- Vercel project configured (can be done via CLI or UI)

**Workflow approaches**:

### Option 1: Automatic (Recommended)
- Let Vercel handle deployment via their GitHub integration
- GitHub Actions only handles validation
- Every push to main triggers Vercel deployment automatically

### Option 2: Manual via GitHub Actions
- Use Vercel CLI in GitHub Actions
- Requires VERCEL_TOKEN secret
- More control but more complex

**GitHub Release notes example**:
```
🚀 Deployed to Vercel: https://project-name.vercel.app

Production URL: https://your-domain.com (if custom domain)
```

## Docker Container Release

**Best for**: Microservices, backend applications, full-stack apps

**Prerequisites**:
- Dockerfile in repository
- Multi-stage builds for optimization (recommended)

**Release targets**:
- **GitHub Container Registry** (ghcr.io) - Recommended, free with GitHub
- **Docker Hub** - Public registry, widely used
- **AWS ECR**, **Google GCR**, **Azure ACR** - Cloud-specific registries

**Workflow steps**:
1. Build Docker image with version tag
2. Push to container registry
3. Also tag as `latest`
4. Create GitHub Release with pull command

**Best practices**:
- Use multi-stage builds to minimize image size
- Run containers as non-root user
- Include health check in Dockerfile
- Version images with semantic versioning

**GitHub Release notes example**:
```
🐳 Docker image: `ghcr.io/username/repo-name:v1.2.3`

Pull and run:
docker pull ghcr.io/username/repo-name:v1.2.3
docker run -p 8080:8080 ghcr.io/username/repo-name:v1.2.3
```

## Binary Artifacts Release

**Best for**: CLI tools, desktop apps, native applications

**Platforms to support**:
- Linux (x86_64, arm64)
- macOS (x86_64, arm64/Apple Silicon)
- Windows (x86_64)

**Workflow approaches**:

### Option 1: GitHub Actions matrix build
Build on multiple runners (ubuntu, macos, windows) and upload artifacts

### Option 2: Cross-compilation
Compile for multiple targets from single runner (works for Go, Rust)

### Option 3: GoReleaser / cargo-dist
Use specialized tools for automated multi-platform releases

**GitHub Release notes example**:
```
📥 Download the binary for your platform:

- Linux x86_64: [app-linux-amd64](link)
- Linux ARM64: [app-linux-arm64](link)
- macOS x86_64: [app-darwin-amd64](link)
- macOS ARM64: [app-darwin-arm64](link)
- Windows x86_64: [app-windows-amd64.exe](link)

Quick install:
curl -L https://github.com/user/repo/releases/download/v1.2.3/app-linux-amd64 -o app
chmod +x app
./app
```

## Python Package (PyPI) Release

**Best for**: Python libraries, CLI tools, frameworks

**Prerequisites**:
- PyPI account and API token
- `pyproject.toml` or `setup.py` with metadata
- Build tool (build, setuptools, poetry)

**Workflow steps**:
1. Build distribution packages (wheel + sdist)
2. Upload to PyPI using twine
3. Create GitHub Release with PyPI link

**Configuration**:
```toml
[build-system]
requires = ["setuptools>=45", "wheel"]
build-backend = "setuptools.build_meta"

[project]
name = "my-package"
version = "1.0.0"
description = "Package description"
authors = [{name = "Your Name", email = "you@example.com"}]
```

**GitHub Release notes example**:
```
📦 Published to PyPI: https://pypi.org/project/my-package/

Install with:
pip install my-package
```

## Rust Crate (crates.io) Release

**Best for**: Rust libraries

**Prerequisites**:
- crates.io account
- CARGO_REGISTRY_TOKEN secret
- `Cargo.toml` with complete metadata

**Workflow steps**:
1. Run tests and validation
2. Publish to crates.io using `cargo publish`
3. Create GitHub Release

**GitHub Release notes example**:
```
📦 Published to crates.io: https://crates.io/crates/my-crate

Add to your Cargo.toml:
[dependencies]
my-crate = "1.0.0"
```

## Claude Code Skill Release

**Best for**: Claude Code skills and extensions

**Prerequisites**:
- Skill properly structured and validated
- Skill packaged as .skill file

**Workflow steps**:
1. Validate skill structure
2. Package skill into .skill file
3. Create GitHub Release with .skill file attached
4. No deployment needed

**GitHub Release notes example**:
```
🎯 Claude Code Skill Release

Download the skill file and install in Claude Code:
1. Download [skill-name.skill](link)
2. In Claude Code, run: /skills install /path/to/skill-name.skill

What's included:
- [Brief description of skill capabilities]
```

## Desktop App Distribution

**Best for**: Electron apps, Tauri apps

**Platforms**: Windows, macOS, Linux

**Workflow tools**:
- **Electron Builder**: Automated builds and updates
- **Tauri**: Rust-based alternative with smaller bundle sizes

**Distribution methods**:
- GitHub Releases with auto-updater
- Platform-specific stores (Microsoft Store, Mac App Store)
- Custom update server

## Platform-as-a-Service (PaaS) Deployment

**Platforms**: Railway, Fly.io, Render, Heroku (legacy)

**Common characteristics**:
- Git-based deployment
- Automatic container building
- Built-in databases and add-ons
- Easy environment variable management

**Workflow integration**:
Most PaaS platforms integrate directly with GitHub - just validation in GitHub Actions, deployment handled by platform

## Release Strategy Selection Guide

### Choose npm/PyPI/crates.io when:
- Building a library or package
- Want maximum distribution reach
- Package manager installation is preferred

### Choose GitHub Pages when:
- Pure static site
- Documentation site
- No server-side logic needed
- Want simple, free hosting

### Choose Vercel/Netlify when:
- Modern framework (Next.js, SvelteKit, etc.)
- Need serverless functions
- Want preview deployments for PRs
- Need automatic optimizations

### Choose Docker when:
- Microservices architecture
- Need consistent runtime environment
- Deploying to Kubernetes or container orchestration
- Complex dependencies

### Choose Binary release when:
- CLI tool
- Desktop application
- Want users to run without installing runtime
- Performance-critical application

### Choose PaaS when:
- Full-stack web application
- Need managed database
- Want simple deployment
- Solo developer or small team

## Multi-Release Strategy

Some projects benefit from multiple release targets:

**Example: CLI tool**
- npm package (for Node.js users)
- Standalone binary (for system installation)
- Docker image (for containerized environments)

**Example: Web framework**
- npm package (for developers)
- Documentation site on GitHub Pages
- Example deployed to Vercel

**Example: Library**
- Language package registry (npm, PyPI, etc.)
- GitHub Releases for changelogs
- Documentation site

## Versioning and Changelog Best Practices

**Semantic Versioning**:
- MAJOR: Breaking changes
- MINOR: New features (backward compatible)
- PATCH: Bug fixes

**Auto-versioning**:
Use commit messages or PR labels to determine version bump:
- `feat:` → MINOR bump
- `fix:` → PATCH bump
- `BREAKING CHANGE:` → MAJOR bump

**Changelog generation**:
- Auto-generate from commit messages (Conventional Commits)
- Auto-generate from PR titles
- Use GitHub's release notes generation
- Tools: semantic-release, conventional-changelog