| name | release |
| description | Create a new release for the Hamr launcher with version bump, git tag, and push |
| license | MIT |
| compatibility | opencode |
| metadata | [object Object] |
Creating a Hamr Release
This skill helps you create releases for the Hamr launcher. It handles version bumping, git tagging, and pushing to trigger GitHub Actions.
Release Process
1. Check Git Log for Changes Since Last Release
git log --oneline $(git describe --tags --abbrev=0)..HEAD
Review commit messages to:
- Determine version bump type (patch vs minor)
- Check if any new plugins were added (look for commits mentioning new plugins in
plugins/directory)
2. Check for New Plugins and Update README
If a new plugin was added, verify it is documented in README.md:
List all plugin directories:
ls -d plugins/*/Check the "Built-in Plugins" table in
README.md(around line 66-96)If a new plugin is missing from the table, add it in alphabetical order:
| `plugin-name` | Description of what the plugin does |Read the plugin's
manifest.jsonto get the correct name and description:cat plugins/<plugin-name>/manifest.json
The Built-in Plugins table format:
| Plugin | Description |
|--------|-------------|
| `apps` | App drawer with categories (like rofi/dmenu) |
| `new-plugin` | Description from manifest.json |
3. Check for Uncommitted Changes
git status --porcelain
Analyze changes to determine version bump type:
- Patch (e.g.,
0.1.1->0.1.2): Bug fixes, minor updates, no new features - Minor (e.g.,
0.1.1->0.2.0): New features or significant changes (including new plugins)
4. Get Current Version
Read the current version from PKGBUILD:
grep '^pkgver=' PKGBUILD
5. Update PKGBUILD Version
Edit the pkgver line in PKGBUILD:
# Example: Update from 0.1.1 to 0.2.0
sed -i 's/pkgver=.*/pkgver=0.2.0/' PKGBUILD
Version rules:
pkgver- Bump for code changespkgrel- Reset to1when bumping pkgver, only increment for PKGBUILD-only changes
6. Commit and Push
git add -A && git commit -m "chore: bump version to X.Y.Z" && git push
7. Create and Push Tag
git tag vX.Y.Z && git push origin vX.Y.Z
The tag format is vX.Y.Z (with v prefix).
What Happens After Release
GitHub Actions will automatically:
- Update the AUR package
- Create a GitHub Release with sorted release notes (by conventional commit type)
Manual AUR Publish
If GitHub Actions fails or manual publish is needed:
./aur-publish.sh
Version Bump Decision Guide
| Change Type | Version Bump | Example |
|---|---|---|
| Bug fixes only | Patch | 0.1.1 -> 0.1.2 |
| Minor improvements | Patch | 0.1.1 -> 0.1.2 |
| New plugin | Minor | 0.1.1 -> 0.2.0 |
| New feature | Minor | 0.1.1 -> 0.2.0 |
| Breaking changes | Minor | 0.1.1 -> 0.2.0 |
| Major rewrite | Major | 0.1.1 -> 1.0.0 |
Complete Release Commands
# 1. Check git log for changes since last release
git log --oneline $(git describe --tags --abbrev=0)..HEAD
# 2. List plugins and compare with README.md Built-in Plugins table
ls -d plugins/*/
# 3. If new plugin found, read its manifest and add to README.md
cat plugins/<new-plugin>/manifest.json
# Then edit README.md to add the plugin in alphabetical order
# 4. Check status
git status --porcelain
# 5. Update version in PKGBUILD (edit pkgver= line)
# 6. Commit and push
git add -A && git commit -m "chore: bump version to X.Y.Z" && git push
# 7. Tag and push
git tag vX.Y.Z && git push origin vX.Y.Z
Checklist
Before releasing:
- Git log reviewed for new plugins
- README.md updated with any new plugins (in alphabetical order in Built-in Plugins table)
- All changes committed
- Tests passing (if applicable)
- PKGBUILD
pkgverupdated - PKGBUILD
pkgrelreset to1
After releasing:
- GitHub Actions workflow completed
- AUR package updated
- GitHub Release created