create-github-release

# Create GitHub Release

Create a tagged GitHub release with release notes and optional artifacts.

## When to Use

- Marking a stable version of software for distribution
- Publishing a new version of a library or application
- Creating release notes for stakeholders
- Distributing build artifacts (binaries, tarballs)

## Inputs

- **Required**: Version number (semantic versioning)
- **Required**: Summary of changes since last release
- **Optional**: Build artifacts to attach
- **Optional**: Whether this is a pre-release

## Procedure

### Step 1: Determine Version Number

Follow semantic versioning (`MAJOR.MINOR.PATCH`):

| Change | Example | When |
|--------|---------|------|
| MAJOR | 1.0.0 -> 2.0.0 | Breaking changes |
| MINOR | 1.0.0 -> 1.1.0 | New features, backward compatible |
| PATCH | 1.0.0 -> 1.0.1 | Bug fixes only |

**Got:** A version number is chosen that accurately reflects the scope of changes since the last release.

**If fail:** If unsure whether changes are breaking, review the public API diff. Any removal or signature change of an exported function is a breaking change requiring a MAJOR bump.

### Step 2: Update Version in Project Files

- `DESCRIPTION` (R packages)
- `package.json` (Node.js)
- `Cargo.toml` (Rust)
- `pyproject.toml` (Python)

**Got:** The version number is updated in the appropriate project file and committed to version control.

**If fail:** If the version was already updated in a previous step (e.g., via `usethis::use_version()` in R), verify it matches the intended release version.

### Step 3: Write Release Notes

Create or update changelog. Organize by category:

```markdown
## What's Changed

### New Features
- Added user authentication (#42)
- Support for custom themes (#45)

### Bug Fixes
- Fixed crash on empty input (#38)
- Corrected date parsing in UTC (#41)

### Improvements
- Improved error messages
- Updated dependencies

### Breaking Changes
- `old_function()` renamed to `new_function()` (#50)

**Full Changelog**: https://github.com/user/repo/compare/v1.0.0...v1.1.0
```

**Got:** Release notes are organized by category (features, fixes, breaking changes) with issue/PR references for traceability.

**If fail:** If changes are hard to categorize, review `git log v1.0.0..HEAD --oneline` to reconstruct the list of changes since the last release.

### Step 4: Create Git Tag

```bash
git tag -a v1.1.0 -m "Release v1.1.0"
git push origin v1.1.0
```

**Got:** An annotated tag `v1.1.0` exists locally and on the remote. `git tag -l` shows the tag.

**If fail:** If the tag already exists, delete it with `git tag -d v1.1.0 && git push origin :refs/tags/v1.1.0` and recreate it. If push is rejected, ensure you have write access to the remote.

### Step 5: Create GitHub Release

**Using GitHub CLI (recommended)**:

```bash
gh release create v1.1.0 \
  --title "v1.1.0" \
  --notes-file CHANGELOG.md
```

With artifacts:

```bash
gh release create v1.1.0 \
  --title "v1.1.0" \
  --notes "Release notes here" \
  build/app-v1.1.0.tar.gz \
  build/app-v1.1.0.zip
```

Pre-release:

```bash
gh release create v2.0.0-beta.1 \
  --title "v2.0.0 Beta 1" \
  --prerelease \
  --notes "Beta release for testing"
```

**Got:** Release visible on GitHub with tag, notes, and attached artifacts (if any).

**If fail:** If `gh` is not authenticated, run `gh auth login`. If the tag does not exist on the remote, push it first with `git push origin v1.1.0`.

### Step 6: Auto-Generate Release Notes

GitHub can auto-generate notes from merged PRs:

```bash
gh release create v1.1.0 \
  --title "v1.1.0" \
  --generate-notes
```

Configure categories in `.github/release.yml`:

```yaml
changelog:
  categories:
    - title: New Features
      labels:
        - enhancement
    - title: Bug Fixes
      labels:
        - bug
    - title: Documentation
      labels:
        - documentation
    - title: Other Changes
      labels:
        - "*"
```

**Got:** Release notes are auto-generated from merged PR titles, categorized by label. `.github/release.yml` controls the categories.

**If fail:** If auto-generated notes are empty, ensure PRs were merged (not closed) and had labels assigned. Manually write notes as a fallback.

### Step 7: Verify Release

```bash
# List releases
gh release list

# View specific release
gh release view v1.1.0
```

**Got:** `gh release list` shows the new release. `gh release view` displays the correct title, tag, notes, and assets.

**If fail:** If the release is missing, check the Actions tab for any release workflows that may have failed. Verify the tag exists with `git tag -l`.

## Validation

- [ ] Version tag follows semantic versioning
- [ ] Git tag points to the correct commit
- [ ] Release notes accurately describe changes
- [ ] Artifacts (if any) are attached and downloadable
- [ ] Release is visible on the GitHub repository page
- [ ] Pre-release flag is set correctly

## Pitfalls

- **Tagging wrong commit**: Always verify `git log` before tagging. Tag after version-bump commit.
- **Forgetting to push tags**: `git push` doesn't push tags. Use `git push --tags` or `git push origin v1.1.0`.
- **Inconsistent version format**: Decide on `v1.0.0` vs `1.0.0` and stick with it.
- **Empty release notes**: Always provide meaningful notes. Users need to know what changed.
- **Deleting and recreating tags**: Avoid changing tags after push. If needed, create a new version instead.

## Related Skills

- `commit-changes` - staging and committing workflow
- `manage-git-branches` - branch management for release prep
- `release-package-version` - R-specific release workflow
- `configure-git-repository` - Git setup prerequisite
- `setup-github-actions-ci` - automate releases via CI