Release Management¶

Klondike provides automated version bumping and release tagging to streamline your release process.

Basic Usage¶

Check Current Version¶

klondike release

Shows the current project version from .klondike/config.json.

Bump Version¶

Bump the version automatically:

# Patch: 0.2.0 → 0.2.1
klondike release --bump patch

# Minor: 0.2.0 → 0.3.0
klondike release --bump minor

# Major: 0.2.0 → 1.0.0
klondike release --bump major

Set Specific Version¶

Set an exact version:

klondike release 1.0.0

Release Options¶

Option	Description	Default
`--bump`	Version bump type (`major`, `minor`, `patch`)	None
`--message`	Custom release message	`"Release vX.Y.Z"`
`--dry-run`	Preview without making changes	`false`
`--push/--no-push`	Push to remote	`true`
`--skip-tests`	Skip running tests	`false`

Dry Run¶

Preview what a release would do without making changes:

klondike release --bump minor --dry-run

Output:

🔍 Dry Run Mode - No changes will be made

📦 Current version: 0.2.0
📦 New version: 0.3.0

Would perform:
  1. Run tests
  2. Update version in .klondike/config.json
  3. Commit: "Release v0.3.0"
  4. Tag: v0.3.0
  5. Push to remote

Custom Release Message¶

Provide a custom commit/tag message:

klondike release --bump minor --message "Release v0.3.0 - Authentication features"

Skip Push¶

Create the release locally without pushing:

klondike release --bump patch --no-push

Useful for reviewing before pushing:

git log --oneline -5
git push --follow-tags

Skip Tests¶

For hotfixes, you can skip the test step:

klondike release --bump patch --skip-tests

Use Sparingly

Only skip tests for genuine hotfixes. Running tests before release prevents broken releases.

What Happens During Release¶

Validation: Checks for uncommitted changes
Tests: Runs project tests (unless skipped)
Version Update: Updates .klondike/config.json
Commit: Creates a release commit
Tag: Creates a git tag (e.g., v1.0.0)
Push: Pushes commit and tag to remote

Semantic Versioning¶

Klondike follows Semantic Versioning:

MAJOR: Breaking changes
MINOR: New features (backwards compatible)
PATCH: Bug fixes (backwards compatible)

Examples¶

Change	Bump	Before	After
Breaking API change	`major`	1.2.3	2.0.0
New feature	`minor`	1.2.3	1.3.0
Bug fix	`patch`	1.2.3	1.2.4

Integration with CI/CD¶

After pushing a tag, you can trigger CI/CD pipelines:

# GitHub Actions example
on:
  push:
    tags:
      - 'v*'

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build and publish
        run: |
          # Your build steps here

Best Practices¶

Always run dry-run first for major/minor releases
Use consistent commit messages for release history
Tag stable checkpoints even between releases
Document breaking changes in release messages
Run full test suite before releases (don't skip)