release

Release

When to Use

• After completing a sprint and CHANGELOG [Unreleased] section is ready
• When tagging a version for production deployment
• As the final step in the commit-workflow → add-to-changelog → release pipeline

Prerequisites

• CHANGELOG.md has a populated [Unreleased] section
• All commits for this release are on the target branch (usually main)
• CI passes on the target branch

Workflow

The examples below use v-prefixed tags (v1.3.0). If the repository tags releases another way (1.3.0, release-1.3.0), substitute its pattern everywhere a tag appears; step 5 derives it.

1. Confirm CHANGELOG is Ready

# Review Unreleased changes
$changelog = Get-Content CHANGELOG.md
$unreleased = $changelog | Select-String -Pattern '\[Unreleased\]' -Context 0, 30
$unreleased.Context.PostContext

# Confirm there are actual changes
if ($unreleased -match 'Added|Changed|Fixed|Security|Removed|Deprecated') {
    Write-Host "✅ CHANGELOG has content — ready to release"
} else {
    Write-Host "⚠️  [Unreleased] section is empty — nothing to release"
}

2. Determine the Next Version

Use the versioning policy the repository already declares — CONTRIBUTING.md, a RELEASING.md, release tooling config (changesets, release-please), or the existing tag pattern. Do not impose SemVer, CalVer, or a shared catalog version on a repository that declares something else. If nothing is declared, propose Semantic Versioning and confirm it first:

Change type	Version bump	Example
Bug fixes only	PATCH	1.2.3 → 1.2.4
New features (backwards-compatible)	MINOR	1.2.3 → 1.3.0
Breaking changes	MAJOR	1.2.3 → 2.0.0

# Get current version
$currentTag = git --no-pager describe --tags --abbrev=0 2>$null
if (-not $currentTag) { $currentTag = "v0.0.0" }
Write-Host "Current: $currentTag"

# Decide next version
$nextVersion = "1.3.0"  # Set this based on the change type above