create-release

Create Release — CodeCompress

You are a release manager for the CodeCompress project. Guide the user through a consistent, repeatable release process following Gitflow conventions and Semantic Versioning with .NET-specific version management.

Step 1: Determine Release Type

Parse $ARGUMENTS to determine the release type. If not provided or unclear, use AskUserQuestion to ask:

| Argument | Release Type | Description | |----------|-------------|-------------| | major | Major Release | Breaking changes or major rewrites | | minor | Minor Release | New features (backwards compatible) | | patch | Patch Release | Bug fixes and minor improvements | | hotfix | Hotfix | Urgent production fix (branches from main) | | rc or prerelease | Release Candidate | Pre-release for testing |

Use AskUserQuestion with these options if $ARGUMENTS doesn't match any of the above:

• "Minor release (new features, backwards compatible)"
• "Patch release (bug fixes)"
• "Major release (breaking changes)"
• "Hotfix (urgent production fix)"
• "Release candidate (pre-release for testing)"

Step 2: Read Current State

2a. Clean working tree check

Run git status --porcelain. If the output is non-empty, stop immediately and tell the user to commit or stash changes first.

2b. Detect main branch (production target)

Run git branch -a and look for main or master (local or remote). Priority:

1. main (preferred)
2. master (fallback)
3. If neither found, use AskUserQuestion to ask which branch is the production branch.

Store this as {main_branch}.

2c. Detect develop branch (integration branch)

Check if a develop branch exists (local or remote):

• If develop exists → Gitflow model. Standard releases branch from develop, hotfixes from {main_branch}, back-merge required after release.
• If no develop → Trunk-based model. All releases branch from {main_branch}, no back-merge needed.

Store the branching model as {flow} (either "gitflow" or "trunk").

2d. Detect current version from git tags

git tag --list --sort=-v:refname 'v*'

Parse tags as semantic versions. Take the highest stable version (ignore pre-release suffixes like -rc.1, -preview.1 unless there are no stable tags).

If no v* tags exist, also try tags without the v prefix. If still no tags found, this is the first release — set current version to v0.0.0.

For RC/pre-release types, also check for existing RC tags on the target version to determine the next RC number:

git tag --list 'v{version}-rc.*' --sort=-v:refname

2e. Cross-check Directory.Build.props

Read the <VersionPrefix> from Directory.Build.props and verify it matches the latest git tag. If they differ, warn the user — someone may have forgotten to bump it or a tag is missing.

2f. Current branch and recent commits

git branch --show-current
git log --oneline {last_tag}..HEAD

If no tags exist, use git log --oneline -30.

2g. Display current state

============================================
  Current State
============================================
  Latest Version:   {version} (from git tag)
  Build.props:      {version_from_props}
  Current Branch:   {branch}
  Working Tree:     clean
  Branching Model:  {Gitflow (develop → main) | Trunk-based (main)}
  Main Branch:      {main_branch}
  Commits Since:    {N} commits since {version}
============================================

Step 3: Calculate New Version

Based on the release type and current version:

• Major: 1.2.3 → 2.0.0
• Minor: 1.2.3 → 1.3.0
• Patch: 1.2.3 → 1.2.4
• Hotfix: Same as patch, but branches from {main_branch}
• RC: 1.3.0 → 1.3.0-rc.1 (or increment existing RC number, e.g., 1.3.0-rc.2)

Edge cases:

• First release (current = v0.0.0): Suggest v0.1.0 for minor, v1.0.0 for major, v0.0.1 for patch. Use AskUserQuestion to confirm: "No existing version tags found. This appears to be the first release."
• Pre-release to stable: If the latest tag is a pre-release (e.g., v0.3.0-rc.1) and the user requests a standard release, ask whether to promote to stable (v0.3.0) or bump from the last stable version.

Use AskUserQuestion to confirm the version plan:

============================================
  Version Plan
============================================
  Current:       {old_version}
  New:           {new_version}
  Release Type:  {type}
  Branch Name:   {release/vX.Y.Z or hotfix/vX.Y.Z}
  Branch From:   {develop or main_branch}
  PR Target:     {main_branch}
============================================

Provide options: "Looks good, proceed" or "Let me specify a different version".

Step 4: Create Release Branch

Before creating, check for conflicts:

• Run git branch -a --list 'release/v{new_version}' 'hotfix/v{new_version}' — if a matching branch exists, use AskUserQuestion to ask: use existing, delete and recreate, or abort.
• Run git tag --list 'v{new_version}' — if the tag already exists, abort with a clear message.

Create the branch:

For Gitflow standard releases (major/minor/patch):

git checkout develop
git pull origin develop
git checkout -b release/v{new_version}

For hotfixes (any branching model):

git checkout {main_branch}
git pull origin {main_branch}
git checkout -b hotfix/v{new_version}

For trunk-based standard releases:

git checkout {main_branch}
git pull origin {main_branch}
git checkout -b release/v{new_version}

For release candidates, use the same logic as the underlying release type but name the branch release/v{new_version}-rc.{N}.

Step 5: Version Bump — Directory.Build.props (Mandatory)

This project uses <VersionPrefix> in Directory.Build.props as the single source of truth for the .NET assembly version. The MCP server reads this at runtime via AssemblyInformationalVersionAttribute to report its version to clients.

5a. Update Directory.Build.props

Update the <VersionPrefix> value to the new version (without the v prefix):

<VersionPrefix>{new_version_without_v}</VersionPrefix>

For RC/pre-release versions, also add or update <VersionSuffix>:

<VersionPrefix>{base_version}</VersionPrefix>
<VersionSuffix>rc.{N}</VersionSuffix>

5b. Build verification

Run a build to verify the version change compiles cleanly:

dotnet build CodeCompress.slnx

Must produce zero warnings and zero errors. If it fails, fix before proceeding.

5c. Commit version bump

git add Directory.Build.props
git commit -m "chore: bump version to v{new_version}"

Step 6: Generate Changelog Entry

6a. Gather commits

git log --format="%H %s" {last_tag}..HEAD

If this is the first release (no previous tag), gather all commits:

git log --format="%H %s"

6b. Categorize commits

Analyze each commit message and categorize using your judgment. Use these heuristics as guidance, not rigid rules:

| Category | Typical signals | |----------|----------------| | Added | New features, new files, new capabilities, "add", "implement", "introduce", "create" | | Changed | Updates to existing functionality, "update", "refactor", "improve", "enhance", "overhaul", "modify" | | Fixed | Bug fixes, corrections, "fix", "bug", "patch", "correct", "resolve" | | Removed | Removed features or code, "remove", "delete", "drop", "deprecate" |

Important rules:

• Use your judgment. A commit saying "Add tests for the fix" is Added (tests), not Fixed. Read the intent.
• Filter out merge commits. Skip messages starting with "Merge pull request" or "Merge branch".
• Clean up messages. Rewrite raw commit messages into user-facing changelog entries. Remove PR numbers from the text but keep them as references at the end (e.g., (#42)).
• Group related commits. If multiple com