Files
GithubRepoRemover/scripts/README.md

4.2 KiB

Release Process Guide

First time setup: Make sure you have the nbgv tool installed before doing anything else:

dotnet tool install -g nbgv

Quick Reference

Check current version

To see what version you’re currently on, just run:

nbgv get-version

Patch release (1.0.0 → 1.0.1)

Want to create a quick patch release? Simply commit and push to main - the version bumps up automatically!

Minor release (1.0.x → 1.1.0)

If you’re looking to add some new features but don’t want to change the major version, do this:

nbgv prepare-release
git checkout main
git merge release/v1.1
git push

Major release (1.x.x → 2.0.0)

Ready to make some breaking changes? Here’s how to bump up the major version:

  1. Open up version.json and change "version": "1.0" to "version": "2.0"
  2. Commit and push those changes to main

Manual release (if things break)

In case of emergencies, you can manually run the GitHub Action:

  1. Head over to the Actions tab
  2. Hit "Build and Release"
  3. Click "Run workflow"
  4. Make sure "Create a GitHub release" is checked
  5. Click "Run workflow" again

How this works

Version numbers

Here's the lowdown on versioning:

  • Patch versions (1.0.0 → 1.0.1): These tick up automatically with each commit to main
  • Minor versions (1.0.x → 1.1.0): You’ll use nbgv prepare-release for these
  • Major versions (1.x.x → 2.0.0): A quick edit in version.json is all you need

When releases happen automatically

The magic happens and releases are created when:

  • You push a non-prerelease version to the main branch
  • OR you give it a nudge manually with the "create release" option

What gets built

Wondering what gets bundled up in each release? You’ll find executables for:

  • Windows x64 (github-repo-remover-win-x64.exe)
  • macOS Intel (github-repo-remover-osx-x64)
  • macOS Apple Silicon (github-repo-remover-osx-arm64)
  • Linux x64 (github-repo-remover-linux-x64)

Step-by-step workflows

Hotfix/patch (most common)

If you’re making a quick fix, here’s what to do:

  1. Make your changes
  2. Commit them: git commit -m "Fix: whatever you fixed"
  3. Push your changes: git push
  4. And you’re done! Release is created automatically

Feature release

Got a new feature ready? Follow these steps:

  1. Make your changes
  2. Commit them: git commit -m "Add: new feature"
  3. Prepare the release with:
    nbgv prepare-release
    
  4. Merge the changes back to main:
    git checkout main
    git merge release/v1.1  # (replace with the version it created)
    
  5. Push it all up: git push
  6. Done deal! Release gets created automatically

Breaking change

Making a breaking change? Here’s the process:

  1. Update version.json to bump the major version:
    {
      "version": "2.0",
      // ... rest stays the same
    }
    
  2. Commit your changes: git commit -m "BREAKING: what changed"
  3. Push it all: git push
  4. That’s it! Release is created automatically

Manual release script

Need to create a tag manually? Maybe testing or automation hiccuped? Here’s how:

# First, see what would happen without actually doing it
.\scripts\create-release.ps1 -WhatIf

# If all looks good, go ahead and create the tag
.\scripts\create-release.ps1

When things go wrong

"Tag already exists" error

If you hit a "Tag already exists" error, it means the GitHub Action is trying to avoid duplicate releases. To sort this out:

  1. Delete the problematic tag: git tag -d v1.0.1 && git push origin :v1.0.1
  2. Manually delete the GitHub release
  3. Either push your changes again or rerun the action manually

Version not incrementing

Not seeing the version increment? Check if you have new commits since the last release. Remember, each commit to main should bump up the patch version.

Check what version will be built

Curious about what version is up next? Run:

nbgv get-version --format json